You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To some extend, a Jupyter server allows to transfer data to a client, that can then work with it, even offline. This is even more the case with real-time collaboration, where CRDTs allow clients to become local-first applications. But in some cases this is not enough, for instance when working on a notebook a kernel is needed in order to execute cells.
Currently, kernels only live in the backend, but with JupyterLite they can run in the frontend using WASM. We can see WASM as a way to serialize code so that it can be transferred over the wire. Once in the browser, a JupyterLab (or JupyterLite) client could fully work offline on a notebook.
Proposed Solution
I'm imagining that a kernel could advertise itself as "downloadable", if it has previously been compiled to WASM. A field, probably in the kernelspec, would point to a directory containing the WASM assets. A JupyterLab client could suggest to download the kernel code when opening the notebook, and use that in-browser kernel, or use the remote kernel, making clear that the in-browser kernel would allow offline work, with the limitations that come with this technology.
The text was updated successfully, but these errors were encountered:
Problem
To some extend, a Jupyter server allows to transfer data to a client, that can then work with it, even offline. This is even more the case with real-time collaboration, where CRDTs allow clients to become local-first applications. But in some cases this is not enough, for instance when working on a notebook a kernel is needed in order to execute cells.
Currently, kernels only live in the backend, but with JupyterLite they can run in the frontend using WASM. We can see WASM as a way to serialize code so that it can be transferred over the wire. Once in the browser, a JupyterLab (or JupyterLite) client could fully work offline on a notebook.
Proposed Solution
I'm imagining that a kernel could advertise itself as "downloadable", if it has previously been compiled to WASM. A field, probably in the kernelspec, would point to a directory containing the WASM assets. A JupyterLab client could suggest to download the kernel code when opening the notebook, and use that in-browser kernel, or use the remote kernel, making clear that the in-browser kernel would allow offline work, with the limitations that come with this technology.
The text was updated successfully, but these errors were encountered: