Unwanted Autosaves (since implementation of Realtime Collaboration)

[mflorea]

@CycleSEC

Looking more closely, it turns out it only appears when real-time collaboration is disabled.

That’s actually a bug. I reported Loading... .

@CycleSEC

If a page requires a major review, it goes through a dedicated review process on a separate page and is republished only after the work is complete and all stakeholders, including those outside the XWiki user space, have approved the draft.

So you’re using a separate draft page for bigger changes. Do you have to be as strict with the saves on the draft page? I’m trying to understand why the history of the draft page is so important. When the content is “republished”, are you taking also the history from the draft page or simply create a new version on the original (published) page?

Also, is realtime editing on the draft page useful for you (putting aside the auto-save behavior)? What about realtime editing on the original (published) page? I guess that’s out of discussion right?

@CycleSEC

For me, it would be much clearer if the checkbox explicitly stated Allow Real-Time Collaboration and Autosave Every 5 Minutes instead of just Allow Real-Time Collaboration. I wasn’t aware that enabling real-time collaboration also meant enabling autosaves.

The thing is that realtime editing needs auto-save. When you are editing alone (and no one else can join), you are the only one responsible for saving your work, and you know it. So you save whenever you think it’s needed. When you are editing the same page with others:

• “all” of you become responsible for saving, BUT, as we know, when all are responsible, none do it (because “other’s will save for sure”)
• you know when your change is in a polished state, but you don’t know about the others editing at the same time; if you save, you can catch others in the middle of an unfinished change. Even if you are in a call, talking to each others, it’s not always easy to synchronize a save when everyone editing is ready (their changes are polished).
• version increment needs to be propagated to all editors, otherwise you get merge conflicts; each editor instance knows the page version they are editing, and this version is submitted on save and checked with the page version from the server; if they don’t match a merge conflict occurs; the realtime editor avoids merge conflicts by making sure the auto-save is not triggered at the same time by multiple editors. Whenever an editor instance wants to save it notifies the others so that they don’t save at the same time. Without this auto-save protocol the users would have to talk to each other (chat or voice) to synchronize on saves. This is not easy.

For these reasons, realtime editing needs auto-save. This also means that it’s not easy to have a clear revision history for the duration of a realtime editing session. We can aim for marking the start / end of a realtime editing session in the page history, grouping or folding the minor edits under some “realtime edit” version, but I’m not sure if we can do more.

There’s also the option to disable auto-save while editing alone, but the problem is that other users may join or leave without you noticing. I’m not convinced that turning auto-save on and off is a good idea.

As for the checkbox label, I find it too long to also mention auto-save. As I said, for me realtime implies auto-save.

Thanks,
Marius