feat(jupyter): add handling for comms #24250
Conversation
Co-Authored-By: Trevor Manz <trevor.j.manz@gmail.com> Co-Authored-By: Kyle Kelley <rgbkrk@gmail.com>
| ...data, | ||
| buffers, | ||
| close() { | ||
| if (closed) { |
There was a problem hiding this comment.
We also need to use an op_jupyter_ I assume, to clean up the mapping on the Rust side.
Co-authored-by: Trevor Manz <trevor.j.manz@gmail.com> Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
cli/js/40_jupyter.js
Outdated
| msgCallback?.({ | ||
| ...data, | ||
| buffers, | ||
| }); |
There was a problem hiding this comment.
Follow up on comment below, to mirror the send API
| msgCallback?.({ | |
| ...data, | |
| buffers, | |
| }); | |
| msgCallback?.(data, buffers); |
|
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, 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
}); |
| let Some(comm) = maybe_comm else { | ||
| return (serde_json::Value::Null, vec![]); | ||
| }; | ||
| comm.receiver.resubscribe() |
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
For widgets, I think it will basically only be one comm listener. There is new comm created for each new widget instance.
|
@manzt quick question What is |
The docs say it's often not used, but in the case of the |
…24373) Moves the ZeroMQ messaging server to a separate thread. This will allow to run blocking JS code and maintain communication with the notebook frontend. Towards denoland#23592 Towards denoland#24250 Closes denoland#23617
|
reopen when it's ready - closing because old |
No description provided.