Proposal: allow for custom control channel messages

[mlucool]

@Zsailer suggested this is the best forum to discuss this idea.

Proposal: Allow for custom control channel messages

By adding this feature, extension authors can innovate around the things a kernel can do. For example, if we wanted to make a restart in place extension (https://github.com/jupyter-server/jupyter_server/issues/596) we may choose to send a message via a control channel to tell the kernel to restart without giving up resources. Or if we wanted to build a non-blocking resource monitor, we could send messages to the control channel asking about resource usage (https://github.com/jupyterlab/jupyterlab/pull/11285). While these are just two example, I suspect that people will come up with a lot of great uses for something like this.

What do people think? If you like this idea, do you have any thoughts on implementation?

CC @Zsailer, @kevin-bates @jess-x @mwakaba2 @echarles @jtpio

[echarles]

From the experiments I have done in https://github.com/jupyterlab/jupyterlab/pull/11285, jupyter-client and jupyter-server both allow already today to pass any message on the control channel.

The UI (e.g. JupyterLab) however is strongly typed and does not allow to create any request which does not respect the jupyter protocol https://jupyter-client.readthedocs.io/en/stable/messaging.html

My understanding is thus how strict or relax the UI would be in terms of protocols respect.

We could try to introduce some level in the protocols with SHOULD, COULD... (like in the Internet RFCs), but this would open a large discussion. The governance model has been recently updated (https://github.com/jupyter/governance/blob/master/decision_making.md) but not sure how easy it would be.

[SylvainCorlay]

An expectation about the control channel is that messages sent to that channel are

• processed concurrently to the other channels (so that we can e.g. send a shutdown message as code is running)
• processed reasonably quickly so that the thread polling the control channel is mostly idle and ready to process a new message.

Allowing for custom messages opens the door to sending very compute-intensive messages, such as widget-like things. I think that we should try to be parsimonious about what is allowed on the control channel, which should be about "controlling" the kernel and doing operations that are "meta" to the application logic (debugging, stopping, starting) and reserved to Jupyter's internal logic.

Note: the two examples (resource usage and restart in place) are of that nature, but I would be very cautious about things such as "comms over controls" which are a slippery slope.

[echarles]

Agree with what @SylvainCorlay says. The question is how to ensure that the new control messages are of that nature. Maybe the need to register some messages. A config file... or pushing more, some crypto signature to verify that the registration is an official one. There are already some signature when you "trust" a notebook, you could extend that idea have a an officiel jupyter signed procedure.

BTW Both jupyter server and client do not implement any validation and act as pass-though for the control channel which is maybe a good time to change that and bring more control, while leaving the door open to extension.

[Zsailer]

I’m in favor of allowing custom control channel messages.

But I also agree with Sylvain’s two “expectations” for messaging across this channel. This channel is best for “meta” logic that happens reasonably quickly. The unique benefit that the control channel runs in its own thread and remains reliable for these meta level actions to run concurrently to the kernel is something we want to preserve. If a kernel begins to flood this channel with heavy computations, it can quickly degrade the other (JEP-approved) tools like the debugger.

I mentioned in the Jupyter Server Team Meeting this week the idea of using this channel for OpenTelemetry like data the flows+spans the whole Jupyter stack. I see the control channel as a good place to flow this such data. It tends to fall inline with the two expectations Sylvain mentioned.

I don’t believe this requires a JEP. I think we simply need to document Sylvain’s two mentioned expectations for the control channel so that kernel implementations follow this as “best practice”.

[echarles]

We discussed also in the jupyter server meeting to open an issue in jupyterlab for this to get a more complete case that encompasses a real ui client. The discussion for jupyterlab is tracked in https://github.com/jupyterlab/jupyterlab/issues/12117, @vidartf has also commented on that.