Rachel Blackman wrote:
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).*snip* Interesting low-cost idea. My main concern would be that while this seems great for something like low-impact shared editing (see SubEthaEdit, for instance), I imagine traditional whiteboarding might be more of a problem.The reason is that people tend to expect simultaneous updates on whiteboards. For instance, if I am drawing on one corner of the whiteboard, and you draw in another area, we each (and anyone else in the whiteboard session) should see those things drawing out simultaneously, or nearly so.
Oops, wrong title. Shared editing was in the original title. How about MUC for your problem? Editing a whiteboard is a lot like a MUC session. You could also allow clients to lock rectangles so that they can complete them before other people get to prod at them.
There must be an initiating entity for a MUW (multi-user whiteboard, kinda catchy, mee-eew), she could keep the final copy of the whole session and handle issues.
As for a conflict, the initiating entity could rectify this, the other users could run and cry to her and she would give the benefit of the doubt to the user who owns the first edit in her MUW history. Remember, people are actively involved here, the initiator can always say, "right, hold on" (she should have a lock all function) and then dig in and fix it. Because of the highly interactive situation, conflicts shouldn't turn out to be a disaster, or do I have it all wrong?
Locking is an age-old technique. If a user wants to edit a text label/area they should first request to lock it, once they receive a lock they can edit away and then release the lock.
If the initiating entity leaves an people still want to carry on maybe control could be passed onto another entity (probably the person who has been in the MUW the longest) in such a fashion:
<will-you-accept-control-of-this-session/> <yes-i-would-be-happy-to/> Needs consideration...
This design seems very useful in a general case, but strikes me as probably generating more traffic than an optimized whiteboard drawing protocol.
I really meant "shared editing". SubEhaEdit looks like fun, but I think text should actually be avoided (all I provided was an example of how diffs can be applied in unicem). I would think XML is really the answer here, because it can be packed neatly in XMPP. The only thing is that it will have to be a diff log for not only the XML structure, but also the inner text of each element (e.g. a paragraph element in a word-processing document could be pretty long).
The problem with applying normal binary/line diffs to a XML file is that namespaces and nesting can go really wrong! SubEthaEdit's methods are also closed, which is a big bummer. So we are essentially going to land up with a diff like this (I would think):
<insert at="someplace"> <f:fubar xmlns:f="foo">Hello</f:fubar> </insert> <!-- The target must ONLY contain text and NO XML elements --> <edit at="someplace"> <insert at="100">bar</insert> <change at="135" length="200">I made this smaller.</change> <change at="135" length="2">And this longer, because I can.</change> <insert at="500">Hello!</insert> <change attribute="style">font-family: serif</change> </edit> <delete at="someplace"/>I have digged up an interesting XML Diff library called 3DM, I will look and see what it can do once I port it to C#.
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
