Open davidbrochart opened 2 years ago
That's super interesting, and for sure be less confusing for the users! :)
Any news on that @davidbrochart ?
I'm actually working in that direction in https://github.com/jupyter-server/jupyverse/pull/364. This PR will allow frontends to be pure shared document renderers, they won't have to speak any other protocol than the Y protocol.
That is great to know, thank you for the feedback :)
I also opened this issue in jupyter-server.
Problem
Currently, terminals are rendered in JupterLab with xterm.js, and the backend serves the "terminal protocol" over WebSocket. This allows collaboration, as the back-end broadcasts terminal events to all front-ends, and so everyone sees what others are doing in real-time. But it doesn't handle conflicts. For instance, imagine a text editing terminal application, like vim. Ultimately, this is equivalent to a shared document, and it will not play well if several users modify it concurrently.
Proposed Solution
I think we could have a "Y shared terminal" document. Actually, it could almost consist of just a
YText
(plus handling of styling, colors, etc.), as far as the Y structure is concerned. But of course the back-end would need to "speak the terminal protocol", and translate that to cursor movement/character insertion/deletion in the YText. We could use pyte for that. Then we could get rid of the terminals WebSocket (as it would go through the Y WebSocket), andxterm.js
in JupyterLab. We would still need a renderer though, for colors and such, but in principle a simple text editor would be enough.Additional context
This is going in the same direction as #12867, basically taking advantage of RTC and reducing the complexity of front-ends: they don't need to speak the kernel protocol or the "terminal protocol".