Thanks @martinRenou, I can work on this early next week and aim to get a draft PR by the next JupyterLab meeting.

I thinking making the core file browser drive configurable is not enough here.

If we only make the file browser plugin configurable here, the e.g. Running Tab plugin will point to different paths than the file browser. Ideally, for the core application to feel self-consistent, we want all references to contents to be consistent unless explicitly asked to fetch from another drive. Alll plugins should be able to assume that they are pulling from the same drive by default.

Instead of just changing the file browser, I would propose that we make the defaultDrive in the ContentsManager API configurable by outside plugins.

I also think we should give the Jupyter Server REST API drive a fixed name, e.g. contents://? Right now, it is implicitly set to default://, which would be a moving target if we let this value become configurable.

Really, this is a question about implicit versus explicit reference of the drive. How do we build a self-consistent core application where we can allow folks to build off of the core contents provider without fear that things will break when say RTC is enabled?

What I found tricky when thinking about all the implications here is that Jupyter collaboration is kind of a special case.

The rtc:// and contents:// drive are (in principle) referencing the same file on disk using different server APIs; so in this case, you actually want to implicitly replace the contents:// drive with the rtc:// drive in all core plugins, unless a plugin explicitly fetches from contents://.

This differs from, say, jupyterlab-github's drive, github:// where most other plugins would never use an implicit path to fetch a file.

Really, this is a question about implicit versus explicit reference of the drive. How do we build a self-consistent core application where we can allow folks to build off of the core contents provider without fear that things will break when say RTC is enabled?

The root issue here is that the Jupyter Server REST APIs do not understand drive prefixes.

So the implicit versus explicit problem is really about what path the Jupyter Server can speak. Jupyter collaboration breaks things because it uses path prefixes that cause weird things to happen on the server.

For example, the Jupyter session database will have references to notebook paths that the server doesn't understand, thus, jumbling the "Running" tab in JupyterLab.

Another example of an issue is that Jupyter collaboration uses the file ID extension to store unique IDs for all notebook paths. When RTC is enabled, you'll begin to see two UUIDs for each notebook, one for the rtc:// prefixed path and non-prefixed path.

Instead of just changing the file browser, I would propose that we make the defaultDrive in the ContentsManager API configurable by outside plugins.

Indeed 👍🏽 totally agree with this, I found out later there was a defaultDrive for the contents manager and I also believe we should allow overwrite it.

Concerning the drive prefix, I assumed the default one was not using a prefix? So if we are able to overwrite the default drive in the case of collaboration, we can probably get rid of the rtc: prefix?