Respect autosave setting in RTC backend

[Darshan808]

Fixes jupyterlab/jupyterlab#14619

Previously, documents were always written to disk on changes, even if autosave was disabled. This PR fixes that by:

• Sending the autosave setting from each client via document awareness.
• Skipping disk writes on doc changes if all connected clients have autosave disabled.
• Writing to disk only when autosave is enabled by at least one client.

The related PR in jupyterlab re-enables manual save in RTC mode. This allows users to save explicitly when autosave is off. On manual save, the frontend sends a save_to_disc message via the document's WebSocket provider, triggering a backend save.

Note: I didn't find a way to determine which client made the change. So if any connected client has autosave enabled, the document will be saved.

Feedback on the approach is welcome!

[github-actions]

👈 Launch a Binder on branch Darshan808/jupyter-collaboration/fix-autosave

[krassowski]

Wouldn't this change user's autosave setting? I think we could just take the value as-is because autosave is the default in lab and notebook.

[Darshan808]

Oh, if autosave is set to true by default, then we don't need this.
Let me go ahead and remove it.

[krassowski]

Note: I didn't find a way to determine which client made the change. So if any connected client has autosave enabled, the document will be saved.

I think this makes sense. If others agree, I wonder if we should make it clear in the UI or at very least document it somehow.

[davidbrochart]

Having autosave enabled when at least one client wants it and disabled when all clients wants it doesn't make sense to me, that's why there was no choice but having autosave enabled in the first place. I have never seen this kind of behavior anywhere. Correct me if I'm wrong but all collaborative applications have autosave enabled (Google Docs...)?

[Darshan808]

I think we can decide how to handle autosave when multiple clients are working on a document. However, what makes the most sense to me is to be able to disable autosave when the extension is installed, but I am working alone on the document.

[krassowski]

Having autosave enabled when at least one client wants it and disabled when all clients wants it doesn't make sense to me, that's why there was no choice but having autosave enabled in the first place. I have never seen this kind of behavior anywhere.

The difference is you can install docprovider without using RTC, this is just to have:

• server-side execution (and offline execution notifications which follows)
• history timeline
• better completion with jupyter-ai

Forcing non-RTC users to use autosave in that scenario is not good because they may (and in fact have, which is why we opened this PR) ran into IO limitations with large enough notebooks stalling high-performance workloads.

So I think what we want to achieve is to:

• respect autosave preferences (on/off, interval) when only one user is connected (regardless of the number of window open?)
• possibly force autosave (if needs be) when multiple users (not clients) connect; this could be enabled by a plugin in collaboration-ui package which could be disabled if users really don't like it, and which could add a flare in UI to indicate that autosave is active (toolbar? statusbar?) with explanation on hover that it was auto-enabled because of multi-user RTC.

Correct me if I'm wrong but all collaborative applications have autosave enabled (Google Docs...)?

Quoting my earlier comment from a month ago jupyterlab/jupyterlab#14619 (comment):

I think the pattern is to enforce autosave in cloud-synced documents, not in collaborative documents; yes most collaborative documents are cloud-synced nowadays, but in cases where they are not, the user still has to deal with their file system limitations and auto-save can lead to inadvertent side-effects, for example if users have file system watch scripts, such as performing expensive anti-virus scans on each modification (which is sometimes enforced and user has no way to disable it).

Databricks also run in issues with autosaving of large notebooks and automatically disables autosave for notebooks larger than 8 MB, see https://kb.databricks.com/notebooks/notebook-autosave

Here is an interesting pattern from OnlyOffice:

How saving works

You can decide when you want your changes sent to Document Server. Find the Autosaving option in the File tab -> Advanced settings:

If autosaving is on, your changes are sent to Document Server (the editors cache) automatically.
If it’s off you need to click the Save button to save your changes in the editors’ cache.

Saving during co-editing

The editors have two co-editing modes – Fast and Strict and they do have influence on autosaving.

In Strict mode, you lock the paragraph you are working on. Others can’t see your changes until you click the Save button, and you can’t see theirs. In this mode, when you click Save your changes are sent to Document Server as usual.

In Fast mode, you can see everything your co-authors are typing in real-time. In this mode, you don’t need to click Save at all – all the changes are saved automatically the second you stop typing. The Save button remains inactive.

https://www.onlyoffice.com/blog/2020/04/save-and-force-save-in-onlyoffice-never-lose-a-document

Another, one is Collabora Office where auto-save is enabled by default but can be disabled (and interval can be configured).

[krassowski]

@davidbrochart did you have time to think about it a bit more? Any other thoughts/suggestions?

[davidbrochart]

I think that we should use a custom message type (see here). Maybe 2 followed by save?

[davidbrochart]

I think that we should use a custom message type (see here). Maybe 2 followed by save?
Also, should we wait for a reply indicating that the file has indeed been saved? Otherwise the following get will probably not return the state of the saved file.

[Darshan808]

Otherwise the following get will probably not return the state of the saved file.

True, But since the signal below is fired after each save from server (due to hash change) and the contents model is automatically updated with the new values, it may not be necessary to wait for the reply here to update the contents model.

jupyter-collaboration/packages/docprovider/src/ydrive.ts

Lines 198 to 200 in 9059310

	this._ydriveFileChanged.emit({
	type: 'save',
	newValue: { ...model, hash: hashChange.newValue },