[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:


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>

<!-- 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>

<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#.

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

More information about the Standards mailing list