On 2/4/08 6:19 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote:
> Boyd Fletcher wrote:
>>
>>
>> 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.
>
but the problem is inherent to the protocol design. in a server side
approach you don't need the complexity of the weighting.
>> 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.
>
if a server side SXE then yes.
>> 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.
I would think we would be considered a very large enterprise collaboration
customer :)
>
> 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
you don't need to build an implementation of something to show that its got
issues. just examining the protocol can provide sufficient evidence.
