Re: [devel] GOCollab, Peer-to-Peer collaborative document preperation.

[Martin Sevior <msevior physics unimelb edu au>]

On Sun, 2005-05-15 at 00:10 +0200, Sven Herzberg wrote:
> Am Samstag, den 14.05.2005, 20:20 +1000 schrieb
> msevior physics unimelb edu au:
> > Here is the link to the document.
> >
> > http://www.ph.unimelb.edu.au/~msevior/abiword/CollaborationFeature-4-2-Journal.zabw
> >
> > You will need AbiWord-2.2 in order to read this.
>
> Hi all,
>
>   read this document. This topic is a very interesting one as I thought
> about that topic too, but I have one important question about collision
> checking/processing:
>
> Imagine Alice and Bob are editing this Text:
>
> Micrsoft Office is great.
>
> Alice replaces "Micrsoft" by "GNOME" while Bob tries to fix the typo.
> How should conflicts like these be detected/organized and solved?


I thought about this. Ultimately this can only be solved by social
engineering. If Alice and Bob have conflicting ideas about what the
sentence says, they have to work them out. The important thing is for
the application to not crash and to remain in synch while Alice and Bob
have they're argument.

One solution is to designate users a priority. If Alice has a priority
greater than Bob and if change records arrive that show they're out of
synch and if they conflict, then Alice's Change Record's win.

The act of replacing Microsft with GNOME in AbiWord actually requires 2
change records. (One to delete (8 chars) Micrsoft and one to insert
"GNOME".)
If Bob makes his change before he sees Alice's, her change record
(removing Micrsoft and replacing it with GNOME), will arrive and
"notice" the synchronization problem (the uid of hers do not come after
the uid's of Bob's). Bob has inserted an extra character in the middle
of her delete. Since Bob's change is in the middle of her change
record's, Bob's change is undone and her's applied instead.

When Bob's Change record arrives at Alice, his change record is "Insert
"o" at location 6". The translation code will see that there is problem.
The text around this location has been changed by Alice. But Bob has a
lower priority than Alice so his changes are discarded and Alice's
changes win.

Then both documents end up like Alice's and the documents stay in synch.

This sort of conflict only happens if the changes occur within the
internet lag time and if the changes occur in the same place in the
document.

However I'm sure something will go wrong at some time so we will also
need a "resynch" button that will resynch the peer-to-peer network with
the document of the user with the highest priority. Our challenge will
be to make the need for a re-synch as infrequent as possible.

Cheers 

Martin


Clearly these will be out of synch. 

I can't think how to automatically recover from this. I'd love to hear
of better ideas
At this point the two authors have to re-synch their documents and carry
on.

> Regards,
>   Sven
> _______________________________________________
> gnumeric-list mailing list
> gnumeric-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnumeric-list