feat(jupyter): add handling for comms

[bartlomieju]

No description provided.

[rgbkrk]

This reformatting must have been caused by defaults in Zed. 😅

[bartlomieju]

I'll revert that before merging

[rgbkrk]

I see why you were hoping to pass in a String here. Lossy creates an owned string whereas std::str::from_utf8 returns a Result<&str>. We could have runtimelib's StreamContent have a method to accept from &[u8] and create the owned string directly. Alternatively, this could just be:

StreamContent {
  name: Stdio::Stdout,
  text: String::from_utf8_lossy(buf),
}

[rgbkrk]

Good catch that this got dropped to simplify.

[rgbkrk]

We'll want to make sure to delete the comm container for this comm id here.

[rgbkrk]

Good catch on this. By the way I did this boxing to pack the enum for jupyter message content more tightly.

[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.