[Standards] shared XML editing update

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 4 23:19:02 UTC 2008

Boyd Fletcher wrote:
> On 2/4/08 5:19 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>> Joonas Govenius wrote:
>>> Boyd Fletcher wrote:
>>>> we still do not believe that SXE is appropriate for whiteboarding
>>>> especially
>>>> when scaled to hundreds of concurrent users in a single session.
>>> I actually think SXE would scale to many users very well because:
>>> a) it makes no difference for an individual client who the edits come
>>> from or how many users there are in the session
>>> b) the server (if one is used) doesn't do any processing of the edits;
>>> it merely forwards them to the participants.
>>> c) SXE causes minimal "locking" of the document; only simultaneous edits
>>> to the same DOM node conflict.
>> That seems reasonable to me.
> but without a server process collisions are going to happen and resolving
> them could be tricky. the whole weighting approach seems to risky. It relies
> on the good behavior of the client way too much.

So we need to document the server mode for SXE.

> also getting current state is extremely expensive and unreliable.  it relies
> on another client to send it to you instead of a more reliable server.

No it does not. The server can send you the state, and in server mode
that might be a MUST.

>>> On the other hand, SXE doesn't currently specify any access control to
>>> limit who can edit the document. That may be a problem for the kind of
>>> large sessions that you're thinking of.
>> IMHO a large session would be done in a MUC room or via a specialized
>> component, and that's the level at which floor control would happen.
> that is kinda how we do it now. we get the access control list from the
> associated MUC room but we don't send the whiteboarding content over the
> MUC. It goes to a separate component on the server.
>>> Also, as Fabio Forno pointed out, SXE may be problematic with a high
>>> volume of edits but, in the case of whiteboarding at least, the volume
>>> would probably not increase very much with the number of participants
>>> because most participant would merely "watch".
>> I think that would be the case for the vast majority of large editing
>> sessions.
> I know of lot of large enterprise collaboration customers that would
> disagree. 

We're not in the business of doing large market surveys or attempting to
divine what people want. If those large enterprise collaboration
customers wish to participate in our open standards process, they are
welcome to do so. If they do not wish to participate (either directly or
via "proxy" through the XMPP server vendors they work with), then their
requirements will not be incorporated.

As far as I can see, many large sessions would be 10 people making edits
and 1000 people listening. It is possible that you could have 1000
people making edits, but personally I think that would get extremely
confusing very quickly, no matter how good your floor control system is.
Maybe I'm wrong about that and I'm just making assumptions, but that is
the kind of system I've been given to understand is more common.

> Any either case, why do we want to push out an approach that has
> such a large potential problem. not to mention the ones described above and
> other emails.

Which are unproven assertions. Let's see how far we can push SXE in the
server-mode direction (so far not fully documented) before we make
judgments about what is and is not workable.


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/20080204/3e8ea6b4/attachment.bin>

More information about the Standards mailing list