[Standards] Shared Whiteboard Editing
Jonathan Chayce Dickinson
chayce.za at gmail.com
Tue Aug 28 23:38:25 UTC 2007
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
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.
jonathan chayce dickinson
email: chayce.za at gmail.com
jabber: moitoi at inflecto.org
<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards