jupyter-server / jupyter_server

The backend—i.e. core services, APIs, and REST endpoints—to Jupyter web applications.
https://jupyter-server.readthedocs.io
BSD 3-Clause "New" or "Revised" License
490 stars 308 forks source link

Collaborative terminals #1040

Open davidbrochart opened 2 years ago

davidbrochart commented 2 years ago

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 commented 2 years ago

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 https://github.com/jupyter-server/jupyter_server/issues/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 https://github.com/jupyter-server/jupyter_server/issues/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 commented 1 year ago

@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 commented 1 year ago

As mentioned here, I'm working in that direction in https://github.com/jupyter-server/jupyverse/pull/364.