On 24 April 2014 06:15, Philipp Hancke wrote:
> Am 24.04.2014 10:58, schrieb Kevin Smith:
>
>> Room logs: http://logs.xmpp.org/council/2014-04-23/
>>
> [...]
>
>> 3) http://xmpp.org/extensions/inbox/rayo-clustering.html
>> Accept as Experimental
>>
>> Lance/Philipp to post their objections to the council/standards lists.
>>
>
> here we go... the requirements make senese. However,
> Nodes and Clients SHOULD NOT be aware of each others identity
> of presence, and SHOULD only communicate with the Gateway(s).
> stated later in section 4.2. actually shows why the XSF does not need to
> standardize this;
> it requires no extensions to a stock rayo client.
>
Not to the client, no, but it's important to the implementation of the
proposed server components (gateways and nodes) which have behaviour that
is beyond that in the XMPP RFCs and requires standardisation for gateways
and nodes from multiple vendors to interoperate, as went my justification
on the other thread.
If the XSF were not to host this specification, where would the appropriate
place be? Rayo is already an XEP, and this is the specification of specific
behaviour of XMPP components, so I don't really see how there is a more
suitable venue...
> ISTR that ejabberd allows multiple components to connect for the same
> domain and then does some kind of session-based loadbalancing.
> This is somewhat more generic but we have not standardized either either.
>
>
> minor issue:
> The spec is also using RFC 2119 language a little too often in places,
> where this is not required for interoperability. E.g. for using two domains
> or when describing load balancing.
>
Is that not something that can be dealt with in the post-publishing review
phase?
>
>
> Using resource identifiers to encode the rayo node, similar to the way
> google talk apparently uses them, might allow the gateway to minimize the
> state kept.
>
>
