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

>> 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.

Tomas
Received on Mon May 16 16:18:01 2005