ellisonbg
commented
1 year 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
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), andxterm.jsin 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".