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

On Mon, 2005-05-16 at 15:15 +0100, Tomas Frydrych wrote:
>
> >> 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.
> >
>
> Ok, I now have had a chance to read through the document, and basically
> lot of what this about is what what is moreorless implemented in AbiWord
> in the revisions/document history mechanism; revisons (or 'tracking
> changes') are about nothing else but collaborative document creation.
>
> There are two differences I can see between how revisions work in AW and
> the proposed system. The first difference is that the document is served
> from a server rather than being a self-contained entity; this is a great
> idea, but ultimately it is really just a formal difference in how data
> is stored and distributed.
>
> The other difference is an assumption that the remote document contains
> a single (latest) state, as for example a document in CVS -- this the
> real Achiles heal of the proposal. The problem with needing to resolve
> user conflicts on the server, as in the example above, derrives directly
> from this 'single-state' property of the remode document. In contrast,
> AbiWord revisioned document contains all previous states stacked on each
> other; this means that a conflict between users' ideas of what should be
> in the document is, from the technical point of view, non-issue, the
> 'conflicting' states simply co-exist until such a time someone resolves
> them (accepts/rejects) the respective changes.
>
> That conflicts where two users disagree on what should be in the
> document can only be resolved through human intervention is unavoidable;
> what you do not want is for work to have to stop for everyone on the
> project until Alice and Bob resolve their difference, nor do you want
> Alice's changes to disappear bellow Bob's without any of the other
> members of the project realising they were ever there. This means that a
> CVS-like system is principally unsuitable for a genuine creative
> collaboration (note that even writing software, a task using a language
> with extremely limited vocabulary and syntax, we still have to have a
> mailing list, without which we would be utterly clueless about what is
> happening to our shared project).
>
> Anyway, I have spent lot of time over the past couple of years
> reflecting on how the differences in user opinion about content should
> be reconciled and presented. Most of the stuff is in the classes in
> pp_Revision.h/cpp, and might save others reinventing the wheel.
>

Hi Tomas,
         Thanks very much for taking the time to read the proposal. As
you say, you've had a lot of experience about the issue of how to
present "revisions" in a document. I'm really glad for your input.

My immediate comments are:

1. The document is not stored on a central server. The document is
located simultaneously at every user in the network. The issue I'm
primarily worried about is how to keep the distributed document in
synch.

2. I need to think more about revisions. You may well be correct that
the work you've done with revisions is exactly what is needed for this
collaborative network. The document as written presents one solution to
the immediate problem of dealing with network latency and how edits
occur in AbiWord. It's like the zeroth order problem that needs to be
solved around latency.

I think the problem of clashes between authors on the same piece of text
is more difficult once the document is distributed. We have to find a
way to prevent clashes within the network latency. Outside the latency
issue, I agree that your revisions work is the best way to track the
efforts of different authors.

Cheers

Martin

> Tomas
>
>
Received on Tue May 17 06:52:04 2005