Hello. In my opinion, cooperative editing the same paragraph does not make sense. I will be annoyed if the paragraph I am editing change from time to time making the structure and meaning and everything a mess. I suggest that we could simply lock that paragraph while others can commenting on it, leaving everything to the editor. And the inline comments act also as a todo list on the editor side, the editor can tick it when the advice is taken, or reply to explain why not. Every comment not ticked should be left for the file owner to make a decision.
On Tue, Apr 30, 2013 at 5:51 PM, Nico Williams <n...@cryptonector.com> wrote: > On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta <tomm...@lyx.org> wrote: >> On 30/04/13 00:23, Nico Williams wrote: >>> Well... If a paragraph is deleted then the pointer might get assigned >>> in a subsequent allocation and... you end up with an aliasing problem. >> >> I was thinking of detecting this problem when you delete a par, going through >> the cursors/pointers potentially affected, but as you say the criticality is >> not local to the LyX instance where the 2 cursors are, that's easy. The >> problem >> is how to synch this forced cursor movement (e.g., going out of the deleted >> region, or the incr in pos etc...) with the remote instance in which that >> cursor is still editing and get the same outcome in both. > > Right. > >>> you don't want to implement a >>> distributed locking protocol (for the same reason). >> >> some locking may be the easy way to avoid some of the biggest problems in >> the first instance. >> I mean, even with git, there are situations of concurrent edit where the >> tool simply cannot >> merge the edits. It has to be done by humans. By locking, you avoid that >> situation to happen. > > git. does. not. lock. (except, in the case of a remote, it locks > briefly around applying commits sent by a client, but what git does > while it holds this lock does not include waiting for I/O from/to any > client.) > > Manual merges may be inescapable. But sometimes you can just avoid it > using brute force. E.g., one user selects and deletes a paragraph (or > more) while another was typing in that paragraph -> just delete the > paragraphs and make the second user have to click somewhere to get a > cursor back. AND, a) let the two users bicker over IM :) b) let the > users undo the winning change (the deletion). > > I haven't thought through all the possible conflicts scenarios, but I > think that as long as the clients eventually exchange enough messages > you can make them converge. > >>> Nor do you want >>> to worry about split-brains (netsplits). >> >> pls, explain ? > > 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. > > 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. > >>> Version everything and assign version numbers; keep history. >>> Alternatively use hash-of-paragraph-contents as version numbers; keep >>> history. >> >> sounds a bit like replicating the git functionality inside lyx...., is it >> really needed ? > > Flatly? Yes. git doesn't know the semantics of the data it deals > with. And git's diff/merge doesn't either. And I suspect that git > diff/merge is not appropriate for merging LyX documents. > >> Let me see: each one keeps a copy of the last edits by everybody, at some >> point the protocol >> sorts out the agreed-upon order of the actions, and each client ensures that >> all actions >> are played back in the same order (e.g., undo-es the last needed # of >> actions, and replays >> them back in the agreed-upon order). Not sure what the GUI (and user-face) >> looks like while >> this is happening ... :-), but it might be needed. > > Yes, this. > > BUT, you should research what Google and others with online > collaboration do. I suspect they have it easier: there's only one > instance of the editor and the GUIs (BUIs) are clients of it, in which > case there's no merging to worry about, no netsplits, nada. > > 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. > > Nico > --
