[Standards] whiteboarding and shared editing
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:
> 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:
> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards