[Standards] Shared Editing (was: Shared Whiteboard Editing)

Joonas Govenius joonas.govenius at gmail.com
Wed Aug 29 17:16:17 UTC 2007

On 8/28/07, Jonathan Chayce Dickinson <chayce.za at gmail.com> wrote:
> 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?

Something pretty important to realise here is that before you can ask
a "master" user to arbitrate the conflict you have to know that a
conflict occured.

Now, if you know that a conflict occured, you probably know which of
the changes conflicted so why not undo both changes? Why involve a
third party to arbitrarily "fix it"?

See http://coccinella.im/memo/sync if you haven't already.

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

At least in SVG based whiteboarding, you'd like to allow several users
to simultaneously append elements to the end of the same tree of child
nodes (of the <svg/> for example). In this case locking would be

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

I agree. I've decribed the same behavior for editing parts of
attribute values in

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

Diff tools like 3DM can be used in two ways: to generate diffs and to
merge them. While the former is the more demanding part for 3DM, I
don't think it's directly relevant to the protocol how the clients
generate the diffs. The latter on the other hand, is relevant but
isn't the difficult part. The difficult part is handling diffs that
don't arrive in the "correct" order.


More information about the Standards mailing list