[Standards] Shared Editing (was: Shared Whiteboard Editing)
Jonathan Chayce Dickinson
chayce.za at gmail.com
Wed Aug 29 00:35:17 UTC 2007
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:
> This design seems very useful in a general case, but strikes me as
> probably generating more traffic than an optimized whiteboard drawing
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):
<!-- The target must ONLY contain text and NO XML elements -->
<change at="135" length="200">I made this smaller.</change>
<change at="135" length="2">And this longer, because I can.</change>
<change attribute="style">font-family: serif</change>
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#.
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