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: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] <some profound piece of wisdom>
smime.p7s
Description: S/MIME Cryptographic Signature
