Boyd Fletcher wrote: > > > On 2/4/08 5:19 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
