Normalize and make Content frontends and backends extensible

Problem

We currently offer a union of files, backed by two storage backends, in the following order:

• pre-baked contents, as indexed in a file tree that roughly mirrors the Jupyter Contents REST API
• in-browser contents, managed by localForage

…with one storage frontend:

• a mock REST API, exposing Jupyter Contents

While this makes it possible to deliver the Lab file management UI, such as it is, it is not very ergonomic for:

• accessing from kernels
• providing alternate storage implementations e.g.
  • WebDAV (a la sharepoint, etc)
  • sqlite
  • git
  • fossil-scm
  • some rando REST API

Proposed Solution

• formalize and define an API for the existing backends
  • these would become two separate server extensions (#104)
• separate the mock REST API frontend from the manager
• add an emscripten-compatible FS frontend for the overall contents

Additional context)

• some upstream thoughts about FS: https://github.com/pyodide/pyodide/issues/1715#issuecomment-900122795
• this may have impacts on #310
  • packages are files, too!
• an example of an FS

[jtpio]

Thanks for sharing this @oeway it looks cool!

[oeway]

FYI: I have been also looking into the storage options, and what I am using right now is using BrowserFS inside a ServiceWorker so we can manage files using varies backends (e.g. indexeddb), and the service worker can work as a in-browser file server. This allows all unified file access via HTTP, and for pyodide kernel, we can do XMLHTTPRequest in synchronous mode and create file-like object that works with large files.

Here is an demo shows how it work in a custom deployment of jupyterlite (available at https://jupyter.imjoy.io ):

Here is the notebook if you want to try it out: https://github.com/imjoy-team/jupyter.imjoy.io/blob/master/docs/files/elfinder-demo.ipynb