Pre-proposal: Querying comm targets in the kernel protocol

[jasongrout]

Background

Currently if a Jupyter Kernel protocol frontend would like check if a certain comm target is registered in the kernel, it has no way of querying if the comm target is registered in the kernel. The comm_info_request kernel message can query for active comms, optionally filtered for a specific target name, but provides no way to query for registered target names.

Proposal

We have two proposals to help in this situation:

1. Add a new mandatory top-level key in the content of the comm_info_reply message of the form: target_names: ['target_a', 'target_b', 'target_c', ...], where the returned values are the registered comm targets. If the comm_info_request had an optional target_name filter, then this filter is also applied to the target_names list (so it is an empty list if the given target name is not registered, and is a list containing the single target name if the target name is registered).
2. Document a new optional data (or metadata?) field reason in the comm_close kernel message giving the reason for closure, with at least one standardized value such as reason: 'target_name not registered'.

Examples

This came up in jupyter-widgets/ipywidgets#3335, where we wanted the frontend to be able to check if the kernel had a specific comm target before using it.

[martinRenou]

This would be a really nice addition to the protocol 👍🏽

We've been facing this in jupyter-widgets/ipywidgets#3335, where we can technically request a comm-open on the target: if this target is not registered, the kernel will show an error message and instantly close the comm.

We can currently rely on this behavior, but it shows unwanted errors in the user terminal. It would be nicer to be able to request information about registered targets prior to requesting a comm-open.

[jasongrout]

Thanks for your comments, @martinRenou!

We also discussed this in the ipywidgets dev meeting with @vidartf, @SylvainCorlay, @ibdafna, etc. Anyone else have thoughts?