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.
If it has to be interactive editing, then perhaps stopping the user is the
right thing to do ?
Or, as you said, we actually need a lyx-aware version control system that
is capable of merging edits, and also ....
> 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.
> 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.
T.
