-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pre-proposal: Querying comm targets in the kernel protocol #86
Comments
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 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 |
Thanks for your comments, @martinRenou! We also discussed this in the ipywidgets dev meeting with @vidartf, @SylvainCorlay, @ibdafna, etc. Anyone else have thoughts? |
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: