You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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 thecomm_info_request
had an optionaltarget_name
filter, then this filter is also applied to thetarget_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).reason
in the comm_close kernel message giving the reason for closure, with at least one standardized value such asreason: '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.
The text was updated successfully, but these errors were encountered: