feat(jupyter): add handling for comms

[bartlomieju]

No description provided.

[rgbkrk]

We also need to use an op_jupyter_ I assume, to clean up the mapping on the Rust side.

[manzt]

Follow up on comment below, to mirror the send API

Suggested change

	msgCallback?.({
	...data,
	buffers,
	});
	msgCallback?.(data, buffers);

[manzt]

Bikeshedding the API... right now you still need to open the comm with broadcast separately ("comm_open") message.

let comm = await Deno.jupyter.commOpen(commId, {
  targetName: "jupyter.widgets",
  data: { /* anywidget stuff */ },
  metadata: { version: "2.1.0" },
});

// either only allow one callback or manage a set of them
comm.on((data, buffers) => {

});

comm.close();

comm.send(data, buffers);

or something more webby (e.g., EventTarget, AudioContext as inspo):

let comm = new Deno.jupyter.Comm(commId, {
  targetName: "jupyter.widgets",
  data: { /* anywidget stuff */ },
  metadata: { version: "2.1.0" },
});

comm.addEventListener("message", (event) => {
  let { data, buffers } = event.detail;
});

comm.removeEventListener("message", /* function */ );

comm.dispatchEvent(
  new CustomEvent("message", { detail: { data, buffers } })
  // or something custom - new Deno.jupyter.MessageEvent(data, { buffers });
);

comm.close();

the latter would be easy to extend for other messages https://jupyter-client.readthedocs.io/en/latest/messaging.html#tearing-down-comms:

comm.addEventListener("close", () => {
  // front-end closed cleanup stuff
});

[bartlomieju]

@manzt @rgbkrk if we go with EventListener approach for a comm then we can expect more than one consumer of the "comm". That means we need to use tokio::sync::broadcast channel which is buffered. We can go with a rather big number for the buffer like 1024 or 65536. If we expect only a single consumer then we could use an mpsc channel that is unbounded. Which one should we go with?

[manzt]

For widgets, I think it will basically only be one comm listener. There is new comm created for each new widget instance.

[bartlomieju]

@manzt quick question

let comm = await Deno.jupyter.commOpen(commId, {
  targetName: "jupyter.widgets",
  data: { /* anywidget stuff */ },
  metadata: { version: "2.1.0" },
});

What is metadata supposed to do when opening the comm? According to https://jupyter-client.readthedocs.io/en/latest/messaging.html#opening-a-comm it's not used.

[manzt]

What is metadata supposed to do when opening the comm? According to jupyter-client.readthedocs.io/en/latest/messaging.html it's not used.

• feat(jupyter): send Jupyter messaging metadata with Deno.jupyter.broadcast #20714

The metadata is required for "comm_open" for with jupyter.widget target. With this PR I can successfully communicate with the anywidget frontend, sending frontend ESM via comms with updates.

The docs say it's often not used, but in the case of the jupyter.widgets front-end target it is required (there is an exception in the frontend when it's missing). So it's metadata that's specific to the targetName, and not necessary for opening any comm I assume.