On 8/24/07, Peter Saint-Andre <[EMAIL PROTECTED]> 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! Joonas
