It could be interesting to be able to connect to an existing kernel, at first just by sharing its connection file, regardless of the security concerns. Every connected client receives the kernel's published outputs through the IOPub socket, and we could redirect them to the right cell if we pass the cell ID that was responsible for the code execution in the parent metadata, maybe.
These are for changes made to the notebook by the kernel. But we also need to synchronize the changes made to the notebook by the user, for instance when a new cell is created, or changed, etc. One option is to have the notebook stored in a shared location, on the web... but that's basically implementing CRDT, which is a good solution when we have a web-based client like JupyterLab, and a Jupyter server.
I'm thinking about a pure socket-based solution. For instance, when a new client connects to the kernel through nbterm, it could "publish" its notebook by e.g. executing print statements of all its cells, with a special header that every other nbterm client would recognize. Basically we would need a small protocol for publishing notebooks on a kernel, and changes made to it. This is a hack, but I'm tempted to try that out :smile:
It could be interesting to be able to connect to an existing kernel, at first just by sharing its connection file, regardless of the security concerns. Every connected client receives the kernel's published outputs through the IOPub socket, and we could redirect them to the right cell if we pass the cell ID that was responsible for the code execution in the parent metadata, maybe. These are for changes made to the notebook by the kernel. But we also need to synchronize the changes made to the notebook by the user, for instance when a new cell is created, or changed, etc. One option is to have the notebook stored in a shared location, on the web... but that's basically implementing CRDT, which is a good solution when we have a web-based client like JupyterLab, and a Jupyter server. I'm thinking about a pure socket-based solution. For instance, when a new client connects to the kernel through nbterm, it could "publish" its notebook by e.g. executing print statements of all its cells, with a special header that every other nbterm client would recognize. Basically we would need a small protocol for publishing notebooks on a kernel, and changes made to it. This is a hack, but I'm tempted to try that out :smile: