[Standards] Shared Editing

[Jonathan Chayce Dickinson]

Joonas Govenius wrote:
> On 8/28/07, Jonathan Chayce Dickinson <chayce.za at gmail.com> wrote:
>> *snip*
>>
> 
> Diff tools like 3DM can be used in two ways: to generate diffs and to
> merge them. While the former is the more demanding part for 3DM, I
> don't think it's directly relevant to the protocol how the clients
> generate the diffs. The latter on the other hand, is relevant but
> isn't the difficult part. The difficult part is handling diffs that
> don't arrive in the "correct" order.

I realised the algorithm has nothing to do with it after I posted. Why I 
thought it would be relevant is so that we can deduce the format in 
which it stores the diff. In reality the diff should not need be 
generated, it would be created concurrently based on the actions of the 
user.

I demonstrated how this could be rectified using the text example 
(effectively merging the diffs to make a new one, which is then applied: 
but this requires a document history of some form, i.e. SVN), although 
something different will be needed for XML.

Why 3DM works nicely is that the references are index based. While you 
may think this is potentially destructive, in reality it is not: if the 
diffs are merged correctly. In a nutshell, because they are index based, 
the diffs can be merged: I just can't think of any way to do it with the 
unique IDs that you are using.

I don't think we are going to run away from a SVN methodology, what I am 
trying to get at is this.

1. Romeo asks to edit a file, and receives it along with a revision 
number (2).
... Many edits occur
2. Juliet asks to edit a file, and receives it along with a revision 
number (10).
3. Juliet submits the edit.
    1. Mediator goes through each revision and merges her diff with the 
standing diff for that revision (in essence each revision's diff should 
it turn into into the most recent revision).
    2. Mediator now creates the new revision with an empty diff.
4. Romeo submits his edits.
    1. [...]
    2. [...]

3DM references each element in an XPath style fashion:

"/0/5/1/2"

Which equates to:

0
  0
  1
  2
  3
  4
  5
   0
   1
    0
    1
    2 *

Merging an insert at "/0/3/1" yields:

0
  1
  2
  3
   0
   1 *
  3
  5
  6
   0
   1
    0
    1
    2 *

Or in other words, the original one will become: "0/6/1/2".

Maybe we can come up with a way to do that with sxde, but I really can't 
think of anything myself. Nor can I think of another way to deal with 
out-of-order submissions.

> 
> 
> Joonas
> 

Regards,
  Jonathan Dickinson

-- 
jonathan chayce dickinson
ruby/c# developer

email:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070829/c0f31266/attachment-0001.bin