When going on-line again and re-syncing with the server the
collaborators will overwrite each others work, leaving the work of the
last collaborator going on-line again as the current version.
E.g. three collaborators A, B and C go to work off-line at the same
time to on the first, middle and last part of a document (rev 0)
respectively.
The go on-line again in the order A, B, and C and thus create three
revisions in which rev 1) only the first part is changed, rev 2) the
first part is brought back to the state before go-ing off-line and the
middle part is changed, rev 3) compared to the situation before going
off-line only the last part is changed.
To actually merge the off-line work of the three collaborators one of
them will need to copy and paste the work of A and B from rev 1 and
rev 2 to compose the final revision in which all changes are in place.

This is a very unsatisfactory solution as essentially the resulting
document should become composed by merging the edits of each
collaborator.
This is difficult to do as a simple 'diff' of the _current version_
with the version re-syncing from of the previously off-line working
collaborator is not correct. The 'diff' should be taken from the last
revision a user was working on on-line and the current re-syncing
version. And the part changed in comparison to 'rev 0' should be
merged with the current version (which may already be changed by the
re-syncing of another user).

The text diff thus can not be a one-to-one 'diff' of one revision and
the re-synching one. There must be some meta-info e.g. per paragraph
that tells where the merging updated should be placed.
E.g.
Suppose collaborator A had worked on paragraph 3, collaborator B on
paragraph 7 and collaborator C on paragraph 15 of the orginal document
'rev 0'.
The merging process should extract the information that the re-syncing
A only changed par 3, and create rev 1 with  this information.
Collaborator B only changed par 7 of the original rev 0 so rev 1
should only be updated with this information creating rev 2.
Finally, the resyncing collaborator C changes should be merged and as
this collaborator only changed par 15 of rev 0 the resulting updating
of rev 2 should only include this paragraph and result in the final
rev 3.

This is of course a simplified and very clean example of what can
happen when collaborators work off-line and re-sync again. And I think
it makes clear why the engineers working on an application like Google
Docs not have implemented Google Gears support yet. Off-line working
and collaboration makes it nescessary to change the look on how a
revision system works best.

I hope this post will give you some inspiration to make Remotewriter
an outstanding tool for both collaborative and off/on-line work.

André (a.k.a. ahab)

T

Yes, merging of revisions from different collaborators is difficult,
and I've deliberately steered away from it at the moment, favouring a
model where each revision in it's entirity is stored, though it's
always possible for a user to compare two revisions and see the
additions / deletions graphically as you can with Google Docs.

This ability to compare revisions is thanks to the diff-match-patch
Javascript library (http://code.google.com/p/google-diff-match-patch/)
written by Neil Fraser, and I've made use of the "diff" part of this
library, though I think maybe the "match" and "patch" parts of this
library could be used to attempt the merging of separate revisions.

If there's enough call for this functionality, then I'll spend some
time looking at it, though my suspicion is that any type of merging
would be difficult to get 100% correct (given that users can do things
like delete and move chunks of text around in a document, thus
destroying any reference points for any merging process). Maybe any
merging algorithm would have to only attempt to merge if it could
detect that there would be a reasonable chance that it would be
accurate?

Thanks for the feedback though!

Jason

On Jan 10, 2:16 am, ahab <ahba...@gmail.com> wrote: