On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta <tomm...@lyx.org> wrote: > On 30/04/13 10:51, Nico Williams wrote: >> Part of the XMPP/whatever fabric gets disconnected from the rest. Now >> you have two LyX instances collaborating but unable to reach each >> other. What do you do now? If each user is allowed to keep making >> changes that are not acknowledged by the other then conflicts will >> pile up, and resolving them will be a mess. But not letting the users >> make progress makes for a poor user experience. > > Guess everybody would love to be able to keep editing, and saving locally > their changes, so that next time (the day after) the other user comes back > on-line, things can synch-up again. But, that sounds a lot like version > control (again), rather than interactive editing.
What's wrong with version control? In fact, re-use the existing change tracking UI but add colors or labels to identify authors. On conflict just pick a winner (deterministically) and the loser will notice (or better: be told). Locking will. not. work. well. Maybe I'm being too categorical but... all my experience says locking won't work. > If it has to be interactive editing, then perhaps stopping the user is the > right thing to do ? I've used a few interactive online collaborative editors before. Not one locked a user out of a paragraph/section/whatever. I can't imagine being pleased with a UI that required the user be aware of locks, even if only in the case of being locked out. OTOH, consider the online editors I've seen (like, e.g., Google docs). You generally get to see other users' cursors and typing almost in real-time if your window has the relevant document sections in view. The very appearance of another user's cursor in a paragraph that you're editing should be enough for you to pop up an IM to the other saying "hands-off man, I'm doing some major surgery on the paragraph". This only fails in the case of netsplits. Now, if one editor is considered a master then the peers that are cut-off from it will stop editing; while if all editors are equal and the whole process is truly distributed and peer-to-peer, then you absolutely need either deterministic conflict resolution (in some cases destructive) or manual conflict merges. I think the latter is a much better user experience. Users know how to talk to each other and arbitrate who works on what. > Or, as you said, we actually need a lyx-aware version control system that > is capable of merging edits, and also .... But you might be able to avoid having to bite that bullet. But if you do bite this bullet, the rest of us will be oh-so-happy. >> Note that once more, a three-way diff/merge tool for LyX here would be >> extremely handy: if two (or more) instances of LyX diverge long enough >> because of a split then one user could do a merge and cleanup >> conflicts, then push the results to the others. > > ... and also being capable of triggering a compare panel (Compare Document > might be re-used here ?) where the user sorts out conflicts. Maybe. But see above. >> For this you could have one instance of LyX act as a master and the >> others do everything via the master, in which case the users of the >> non-master instance will feel latency (but no worse than with any >> other client/server collaboration editors). This will probably be a >> lot easier. > > You mean, edits actually happen only on the master, and each client/slave > only sees updates as reflected and serialized by the master ? yes, a lot > easier, but perhaps very slow/unusable over the Internet. Yes. Well, no, it works for Google and others. Over an XMPP fabric it should work fine too. On netsplit the non-master peers cut-off from the master can stop allowing local edits, or fallback on conflict resolution later when the netsplit is resolved. Offline collaboration (e.g., online when I'm not on an airplane, offline when I am) would be wonderful, and this is where true 3-way diff/merge with LyX semantics would be awesome. Nico --
