Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support JupyterLab>=4.0 #16

Open
bollwyvl opened this issue Oct 14, 2022 · 3 comments
Open

Support JupyterLab>=4.0 #16

bollwyvl opened this issue Oct 14, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@bollwyvl
Copy link
Contributor

Problem

One of the larger breaking changes from JupyterLab 4.x will apparently be landing on the 3.6 line, namely the frontend expecting a jupyter_server_ydoc-compatible WebSocket server.

This should provide missing identity features, and fixes for total-data-loss bugs when working with many users in RTC.

Proposed Solution

NB: I really don't know what I don't know about everything happening here, and would greatly appreciate any help from others more knowledgable 😍.

Ideally, implementing this change should still result in a lightweight, low-config labextension (and likely liteserverextension) that only requires a public or self-hostable (#4), signaling-only server process.

LiteServerExtension

Provide the same features as the https://github.com/jupyter-server/jupyter_server_ydoc/blob/v0.1.12/jupyter_server_ydoc/ydoc.py#L86.

For a full JS solution, it would be a relatively deep stack including

Ultimately, it may still require a source of truth, a leader election process, or something, which may not be provided by a "naive" public yjs signaling server. Keeping this property may require an even more exotic implementation when it's all clients.

JupyterFrontEndPlugin

Update the provider (and related features) to match jupyterlab/jupyterlab#13222 (or whatever ends up being the final state).

Alternatives

LiteServerExtension

  • use the absolute lightest-weight python jupyter_server_ydoc-compatible implementation
    • if this didn't require replacing the entire jupyterlite server (contents, etc) a la Use jupyverse as a "real" server jupyterlite#779
      • this could be feasible if even viewing a file isn't blocked by the (much larger than ywasm) emscripten machine starting up

Additional context

@bollwyvl bollwyvl added the enhancement New feature or request label Oct 14, 2022
@jtpio
Copy link
Member

jtpio commented Sep 11, 2023

Renamed the issue to "Support JupyterLab>=4.0" since we are skipping 3.6.

@jtpio jtpio changed the title Support JupyterLab>=3.6 Support JupyterLab>=4.0 Sep 11, 2023
@jtpio
Copy link
Member

jtpio commented Sep 11, 2023

Also the new / updated extension will probably start from scratch anyway, as the upstream RTC implementation has changed drastically, and there is no notion of document providers anymore.

Which means the implementation could be done in a separate repo and this one be archived.

@westurner
Copy link

westurner commented Sep 13, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants