Skip to content
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

Open
jasongrout opened this issue Jan 26, 2022 · 2 comments
Open

Pre-proposal: Querying comm targets in the kernel protocol #86

jasongrout opened this issue Jan 26, 2022 · 2 comments

Comments

@jasongrout
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

jasongrout commented Feb 4, 2022

Thanks for your comments, @martinRenou!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants