[Standards] whiteboarding and shared editing

Peter Saint-Andre stpeter at stpeter.im
Tue Aug 28 02:28:12 UTC 2007

Joonas Govenius wrote:
> 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.

Right. I think the approach that you and Mats have outlined is a bit
more flexible, since it does not depend on having a master.

> 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 

That's a good way to put it.

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

Isn't the source format for Abiword XML?

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



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070827/5ede350b/attachment.bin>

More information about the Standards mailing list