Joonas Govenius wrote: > 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.
Agreed. >>> 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
