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

> Since the GNOME (and Gtk) Free Software world contains beautiful and
> powerful communication tools like gaim, xchat, gnome-meeting and
> evolution we have the opportunity to go one better than both MicorSoft
> and Apple by providing immediate collaborative document development in
> our productivity apps.
>

I think synchronised real time editing is an interesting idea, but as
long as that is all it is (i.e., no off-line editing, no audit trail),
it is extremely limited in it's usefulness in the real world -- I think
the reason why M$ or Apple do not provide this kind of service is not
because they would have not though of it, but precisely because of it's
limitations.

Nevertheless, I think as proposed this would make an excellent first
step toward collaborative facilites in Gnome Office, but I would like
even that first step to be taken with vision toward a more powerful
system, so that the protocol (and its AbiWord implementation) could be
used in a scenario where a centralised server runs AbiWord in a console
server mode, serving potentially large number of documents at the same
time to a large number of clients. The server/client handling of this
scenario would be very easy to implement because the current revisions
and versioning mechanisms provide virtually all that is needed for this;
I recon that if a suitable protocol was in place, I could implement this
in 3-4 weeks.

What I would need from the protocol for this is:

* Each packet of the protocol carrying a uuid identifying which document
it pertains to (we have AD_Document::getDocUUIDString() for this).

* Set of apis allowing generic communication between the client and the
server, not just sending chg records; the sending of chg record should
be a particular case of the protocol communication. Something like
having a function:

collabCmd(const char * cmd, const char * param, const char * token),

where chg record would be dispatched as collabCmd("CHANGE", "the change
...", "token/lock");

the token would be requested as collabCmd("GETLOCK", "", ""); and
received through ["LOCK, "the lock", ""] packet, and it would identify a
  command packet as legitimate in subsequent communication.

The token would need to be time limited; obviously in the synchronous
real time collaboration, the lifetime would need to be quite short; for
the server/client operation it would need to be longer. Therefore, the
protocol should not have this hard-wired, but the expiry time should be
encoded in the token itself: perhaps standard UUID in which the time
information would be changed to indicate the expiry rather than orgin.

I have some more thoughts on this, but have to get to work now.

Tomas
Received on Tue May 17 10:19:32 2005