Hi Martin,
> 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.
I think this where the proposal makes things unnecessarily difficult for
itself. I think one of the AbiWord instances, that of the the user who
initiate the collaboration, should function as a server and the changes
should be done against the document stored on that machine. You would
need some mechanism for one of the other AbiWords taking over if that
particular user quits unexpectedly (the instance that first discovers
the server is gone should take over), but that should not be too
difficult. I think the server/client approach would make things easier
to manage, and would be easy to extend to allow for off-line editing as
well.
As for keeping things in sync, I think Dom is right; you need to be
passing a token (or in the server/client context, using a server lock).
>
> 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.
The revision system circumvents this problem. Because in a revisioned
document there are no deletes (only notional deletes), it is always
possible to apply a change record to the document even though the
document has changed since the record was generated (all you need to do
is to adjust the change record's coords to reflect the subsequent changes).
However, if you are only interested in real-time editing, passing a
token that has a limited life-span resolves the latency problem.
Tomas
Received on Tue May 17 08:44:03 2005
This archive was generated by hypermail 2.1.8 : Tue May 17 2005 - 08:44:03 CEST