Collaborative terminals

[davidbrochart]

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), and xterm.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 #900, 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".

[ellisonbg]

I think this makes lots of sense. We should make sure to test it for lot of applications, especially those with complex layout and events.

…

On Fri, Oct 28, 2022 at 8:13 AM David Brochart ***@***.***> wrote: Problem Currently, terminals are rendered in JupterLab with xterm.js <https://xtermjs.org>, and the backend serves the "terminal protocol" over WebSocket. It 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 it would need to "speak the terminal protocol", and translate that to cursor movement/character insertion/deletion in the YText. We could use pyte <https://github.com/selectel/pyte> for that. Then we could get rid of the terminals WebSocket (as it would go through the Y WebSocket), and xterm.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 #900 <#900>, 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". — Reply to this email directly, view it on GitHub <#1040>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUC4MDUTOERGKQQOIWTWFPUPZANCNFSM6AAAAAARRFKMUM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[kzgrzendek]

@ellisonbg

I'm also uping this issues ; we're providing a jhub collaboration environments to our users, and I know they would be much less confused about terminals in collaborations thanks to that proposition :)

[davidbrochart]

As mentioned here, I'm working in that direction in jupyter-server/jupyverse#364.