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.
> 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.
> Nor do you want
> to worry about split-brains (netsplits).
pls, explain ?
> 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 ?
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.
T.
