[Standards] whiteboarding and shared editing

Joonas Govenius joonas.govenius at gmail.com
Sat Aug 25 12:49:58 UTC 2007

On 8/24/07, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> >
> > I tend to think that in the link-local case the most interesting case is
> > the multiple user one (imagine doing that at a conference or in a office).
> I think the OLPC folks have done some work on multi-user communications
> over link-local messaging. See also:
> http://www.xmpp.org/extensions/inbox/private-muc.html

That's interesting. As long as the "central client" sends the messages
to all participants in the same order there should be no problem using
sxde in such PMUC.

> > Maybe it could even be done electing a peer as arbitrator, but if it is
> > really distributed it would be a lot better (no election, no arbitrator
> > going away).
> >
> > I know that the Abiword people have something similar in AbiCollab
> > running over DBus tunnelled in XMMP,
> Cool, I didn't know about that.
> > so it may be useful to look at
> > their conflict resolution algorithm and their way to send changes.
> It seems to be described here:
> uwog.net/~uwog/abiword/abicollab.pdf

That's a really nice description.

It's actually quite similar to Mats' method (that sxde is using for
synchronizing individual elements) except that their basic principle
is "the master is always right" where as Mats' principle could be
described as "no one is right" in the case of a collision. I.e.
Abicollab forces the slave to always revert colliding changes while
Mats forces all clients to revert colliding changes. In both cases
however, the idea is to keep an undo stack that can be used in case of
a collision.

Abicollab also has a more complex method of determining which changes
collide. This is a good idea for them as it seems that they treat the
whole document as one long string, otherwise collisions would happen
all the time. We could use the same algorithm for synchronizing
individual text nodes but, while this maximizes the number of
commutative edits (req. 2.3.5 in XEP-228), I think it would be
unnecessarily complex and would lead to useful results only in the
case of long text nodes.

In short, unless we want to go the way of treating the whole document
as one long string, I don't think we'll have a whole lot to learn from
Abicollab, except for their excellent description of the protocol!


More information about the Standards mailing list