Collaborative editing

[ferndot]

Yes, the title says it all! This issue is to track the progress of implementing a collaborative editing environment.

[HR]

I think that we should keep this out for v0.4 because we are already having quite a lot of change(UI) and rather add a lot more editing features that are important.

[twiss]

I'd like to make a case for locking here (e.g., when you edit a paragraph, for some time nobody else can edit that paragraph). From https://neil.fraser.name/writing/sync/ (all of which is interesting):

Locking is the simplest technique. In its most basic form, a shared document may only be edited by one user at a time. A familiar example is Microsoft Word's behaviour when opening a document on a networked drive.[?] The first user to open the document has global write access, while all others have read-only access. This does not allow for real-time collaboration by multiple users.

A refinement would be to dynamically lock and release subsections of the document. However this still prevents close collaboration. Subsection locking also restricts editability when the document is small. Furthermore, support for fine-grained locking would have to be explicitly built into the application. Finally, locking is ill-suited for operation in environments with unreliable connectivity since the lock or unlock signals can get lost, leaving no owner.

However, my experience with Google Docs is as follows: I create a document, send the link to a couple others, I start typing a paragraph, they delete it. Repeat for three minutes. (In hindsight, I should've first started typing and then sent them the link. Or maybe I should just think happy times.) Of course, this was in school and it's different when all want to do something. However, even then I'm not convinced of the value of two people working in the same paragraph. If you want to suggest improvements, you can point them out verbally. (Also, we should provide a way to actually point.) Thoughts?

[Ryuno-Ki]

Finally, locking is ill-suited for operation in environments with unreliable connectivity since the lock or unlock signals can get lost, leaving no owner.

This should not be underestimated. Especially as mobile connection turns out to be unreliable. Maybe a timeout from the last cursor movement? After that, unlock the paragraph automagically.

[ferndot]

Do you guys think that we should implement our own system, or use a library (e.g. TogetherJS)? In the latter case, we would not have to worry about locking.

[twiss]

It does look like they support contenteditable (https://github.com/mozilla/togetherjs/pull/931), so it's worth a try.

[twiss]

How will this work though? If you have a document in your Device Storage, and then share it for others to edit, and then log off, then either

1. They can't edit it anymore
2. We have a server and when you come back online the file is automatically or manually updated (breaks if you edit the file with another app, unless we're notified, and also if you edit the file while offline, unless we have our own merging)
3. You can make documents shared by moving them to the cloud, be it GDrive or our own server
4. Firefox OS provides a way to share Device Storage files
5. We ditch the idea of others editing your file and allow them to "propose changes" instead, which we then apply (good for reviewing documents, but not for creating together)

3 + 4 would be the most elegant solution, even though whether and how it works would be storage-specific. 2 might be doable with a modified version of TogetherJS (that waits with delivery of events until clients come back online).

[ferndot]

I think that we should do approach 3 initially. It is less likely to break and lose data.