stream:features

[Brett Zamir]

I'd like to add a new state once <stream:features> is detected--in order
to pass this element's contents back to the application. The closest
existing state would be "accept-stanza" in that it allows an element to
be passed back and triggers observers, but as you pointed out before,
stream-level elements are not 'stanzas', so my question would be whether
we might rename "accept-stanza" or add a new state.

One reason I wish to return this information is so as to avoid an extra
initial call to the server by detecting whether jabber:iq:register
support exists, as the In-band Registration protocol adds a
<stream:features> child:
http://www.xmpp.org/extensions/xep-0077.html#streamfeature . There are
also other stream feature elements that might be sent:
http://www.xmpp.org/registrar/stream-features.html

thanks,
Brett

[Massimiliano Mirra]

On Tue, Sep 16, 2008 at 2:57 AM, Brett Zamir <bre...@gmail.com> wrote:
> One reason I wish to return this information is so as to avoid an extra
> initial call to the server by detecting whether jabber:iq:register
> support exists, as the In-band Registration protocol adds a
> <stream:features> child:
> http://www.xmpp.org/extensions/xep-0077.html#streamfeature . There are
> also other stream feature elements that might be sent:
> http://www.xmpp.org/registrar/stream-features.html

The client code should be shielded as much as possible from the phase
of stream set-up. Obviously this ideal can't be attained in the case
of errors, but we should try to stick to it for normal operation. For
your use case, I think you could save stream features and make them
available as a (read-only, of course) attribute of the session object.

[Brett Zamir]

Massimiliano Mirra wrote:

On Tue, Sep 16, 2008 at 2:57 AM, Brett Zamir <bre...@gmail.com> wrote:
  

One reason I wish to return this information is so as to avoid an extra
initial call to the server by detecting whether jabber:iq:register
support exists, as the In-band Registration protocol adds a
<stream:features> child:
http://www.xmpp.org/extensions/xep-0077.html#streamfeature . There are
also other stream feature elements that might be sent:
http://www.xmpp.org/registrar/stream-features.html
    

The client code should be shielded as much as possible from the phase
of stream set-up.  Obviously this ideal can't be attained in the case
of errors, but we should try to stick to it for normal operation.  

Sorry, but I'm not sure what you're saying here. You mean setting a distinct state wouldn't be shielding it from client code? By client code, do you mean the non-connector xmpp4moz client code (like client_service or jsapi), or the application code built on top of xmpp4moz? If the former, the stream features would still need to be surfaced from the connector and session code somehow, and if the latter, the whole idea of extensible stream features is to be able to let the client code be able to change accordingly (and if named distinctly wouldn't interfere with existing implementations).

Btw, I've found another case where I would want to rely on stream feature detection: Entity Capabililities: http://www.xmpp.org/extensions/xep-0115.html

For
your use case, I think you could save stream features and make them
available as a (read-only, of course) attribute of the session object.
  

Save them via what route? If I don't use an observer, one would presumably need to keep polling the property which would make it fairly cumbersome to access.

Brett