[Standards] Shared Whiteboard Editing

[Jonathan Chayce Dickinson]

Right, I'm back... I have been on the internet for some time, and I 
really should have had a thicker skin about the issue. ID-10-T error, I 
should take my computer back to the store and consider another career 
;). Sorry about the cheap shot Peter.

I'm not too hot on Jingle, so I will leave that to you. However, I did 
have an idea for shared whiteboard editing (or any file for that matter).

It runs as follows:

1. The mediator (or host of the session) has something like and SVN 
repository (hell, an SVN repo would be great as-is).

2. The others check out the most recent files.

3. They make their edits, what is important is that the editing software 
in question keeps a copy of the original checked-out file so that it can 
generate a diff.

4. The user checks the file in, but only sends data generated by the 
diff algorithm (of course, a suitable one needs to be chosen and fixed 
for each MIME) and the revision they were working against.

5. This is the tricky part. The mediator must now use that diff to 
update to the latest version. Here is the basic flow of that:


The mediator takes all the diffs submitted since the revision that the 
user was working on and offsets the newly submitted diff according to 
those. e.g. (insert X bytes at Y bytes position)

previous diff1: (insert 10 at 100) (insert 20 at 200)
previous diff2: (insert 6 at 10) (insert 5 at 150)
new diff3: (insert 10 at 180) (insert 20 at 500)

Note: diff1 created revision 700, the original diff2 was made from a 
file checked out from revision 690, but now it is relevant to revision 
700 i.e. what it turns out to be after the process below.

So now the mediator knows where the new data must be placed/deleted/changed:

after considering diff1: diff3 == (insert 10 at 190) (insert 20 at 530)
after considering diff2: diff3 == (insert 10 at 201) (insert 20 at 535)

That would only work for textual data. The problem with defining a 
method for collab is the different data types: but I'm sure a solution 
could be made for each one, I can even think of ways to apply changes to 
raster images (alpha layering for a start).

Alternatively you could require that all data that is collaborated over 
XMPP need be in a XML format, and then come up with a viable solution 
for that. Tell me to go figure and I will try and come up with something 
reliable.

Otherwise, there is this article: 
<http://portal.acm.org/citation.cfm?id=143473> and it is cited by quite 
a few people, I just don't subscribe to that journal.

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/bef56709/attachment-0001.bin