[Standards] Rayo feedback.

Kevin Smith kevin.smith at isode.com
Fri Sep 4 10:51:28 UTC 2015


Picking this main point to reply to:

On 3 Sep 2015, at 20:15, Ben Langfeld <ben at langfeld.me> wrote:
>>> 33) 6.5.4 - How is discovery of the optional/extensible mechanisms discovered?
>>> 
>>> It's not. Server documentation only.
>> 
>> If it’s not discoverable, how would a client written without reference to a particular server’s documentation interoperate with it?
>> 
>> It would not, and it could not reasonably hope to. I see no benefit to discovery here; it wouldn't change the situation any.
> 
> I’d like to be sure I understand this, because it seems somewhat important. Do you mean that following XEP-0327 is not sufficient to implement a Rayo Client (or server)?
> 
> Please explain how Disco would make any difference.
> 
> 
> It's not specifically disco, any discovery mechanism would do.
> 
> If I have implemented a Rayo client, how does it know whether the server it's using will support its required and/or supported mechanisms?
> 
> And my counter-point: once it discovered such information, what would the client do with it?
> 
> We could just pretend that I have a general dislike of things which *could* be discoverable but aren't.
> 
> But in practical terms, you seem to be insisting that a client is something written specifically for a particular server.
> 
> In which case what good is it doing to put this specification through the XSF?
> 
> Any client library or framework (see Adhearsion/Punchblock for precedent) would not benefit in and of itself from any such discovery, much the same way a generic XMPP library would not. An application based on those libraries would use certain features of the specifications which impact the choice of server implementations they have.
> 
> If a specific group chat application was looking for an XMPP server, it would have to (components aside) choose one which implements the server-side parts of MUC) for example. If a MUC-specific client application was used against a server which does not implement MUC, then the best it could hope to do is fail to launch saying "get a better server”.

I think the point here is subtly different, though. If you have a MUC client and a MUC server, you know they will interoperate. There are a few optional features that one or the other might not support - but these are known to be optional, so the entities must be coded accordingly. Most of MUC is a baseline, and you know that the client can join MUC rooms, see who’s in them, chat, etc. etc. etc.

On the other hand, with Rayo, it seems from my position of ignorance that you might have a Rayo client and a Rayo server, but for them to not interoperate usefully at all, as they might have completely different URI schemes, etc. etc. etc. I would expect that any two entities implementing a XEP would be able to interoperate at a known baseline, and that the optional features would be defined.

(Also, yes, in XMPP it’s usual to know in advance if things aren’t supported, through disco, rather than roundtripping to find out with an error)

/K


More information about the Standards mailing list