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

[msevior physics unimelb edu au]

> Hi Martin,
>
> I'm puzzled. It seems like you are talking about
> things getting out of sync as if it were either
> acceptable or unavoidable.
>
> There are ways of coordinating activity so that
> nothing gets out of sync.  One simple one goes back to
> my kindergarden days - you must be the only person in
> the room holding a particular token before you can
> talk. When you're done talking, you give that token
> back to the teacher so that someone else can talk. But
> there are other solutions to this problem too.
>
> I'd hate to see us create a mess for ourselves (and
> our users), especially when solutions to the problem
> are known in advance.
>
> This message is also puzzingly cross-posted.
>
> Best,
> Dom

Hi Dom,
        I announced this with the aim of inducing feedback. I think the
token passing scheme is a good idea. It might produce an
acceptable lag for widely dispersed people on the internet. You
still have the problem of potentially several people asking for
the token within the latency of the internet. Who gets the token?
I guess it could decided on the basis of priority.

I've restricted the reply to gnome-office apps since they're the primary
audience for this. I announced it to gnome-hackers because I thought it
was interesting enough for a wide audience.

Cheers

Martin

> --- Martin Sevior <msevior physics unimelb edu au>
> wrote:
> > 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
>
>
>
> __________________________________
> Yahoo! Mail Mobile
> Take Yahoo! Mail with you! Check email on your mobile phone.
> http://mobile.yahoo.com/learn/mail