Deno Userland Jupyter Messaging library: `comms`

[rgbkrk]

The Jupyter comms protocol

Jupyter has the concept of custom messages that are bidirectional messages between a frontend and the kernel. Famously, these are used to implement the IPython widgets. At the most basic we need a way to listen for comm messages on a particular comm_id. Comm messages come in on the shell channel while responses will go out on iopub.

The spec itself is pretty short as all we have to implement messaging wise is sending comm_open, comm_msg, and comm_close.

Userland libraries will want to register to be available for when the frontend requests a comm_open so that they can receive all comm_msg for a given comm_id. Given Deno's commitment to web standards, I'm assuming we would use event listeners.

Motivations

The big reason to implement these messages is to be able to create two-way data bindings that allow you to set values on objects both in the frontend and the backend:

This gives us forms, interactive maps, etc.

Where, to me, it gets more wild and interesting is being able to send esm and css code with anywidget. cc @manzt

In order to get there though, we have to start with the primitives for comms sending and receiving in the rust portion of the kernel.

[bartlomieju]

@rgbkrk FYI we already "support it", by always closing the opened comm channel here: https://github.com/denoland/deno/blob/cf6f649829fbb0562681bc9db0c4c1261d4a40b1/cli/tools/jupyter/server.rs#L223C8-L228

I think we need a concrete case and just set up proper responses based on provided target name; doesn't seem so bad to handle 👍

[rgbkrk]

FYI we already "support it", by always closing the opened comm channel here

I love spec compliance. 😄

I think we need a concrete case and just set up proper responses based on provided target name; doesn't seem so bad to handle

I'll come up with a small concrete case to work with because diving headfirst into the IPython widgets is going to require a lot of yak shaving.

[rgbkrk]

Prior art: https://github.com/ipython/ipykernel/blob/main/ipykernel/comm/comm.py

[giswqs]

This is very interesting! It would be a game-changer to be able to use JavaScript libraries directly within Jupyter notebook to communicate with ipywidgets such as ipyleaflet.

[giswqs]

It is quite challenging to add a new plugin in ipyleaflet. We need a simpler way.

https://github.com/jupyter-widgets/ipyleaflet/pull/1138

[bartlomieju]

@giswqs I had a talk with Kyle the other day and we have a way forward - just need to put a foot in the door with the first comm. We tentatively agreed we're gonna add "lint" functionality that would use a comm (and a frontend for that matter) which would allow us to build out the functionality as needed.

[giswqs]

I am very excited for this! Looking forward to trying it out when it becomes available

[rgbkrk]

We've made some progress on this with:

• 20656

• 20710

• 20714

You can see a bit of a demo usage in https://github.com/manzt/anywidget/pull/311