[Standards-JIG] Client Capabilities (rant)

Chris Mullins chris.mullins at coversant.net
Sun Nov 20 19:20:12 UTC 2005


Iam wrote:

> Hi Chris, I'm sorry to hear that you had such a 
> frustrating time working with client capabilities. :-(

Me too! 

> > 1 - Check presence and see if any JEP 115 capabilities are listed.
> > If any of these are listed, we need to just ignore them, as they're
> > client specific anyway and of no use to any other client. This JEP#
> > is of no use for general client capabilities and should be either
> > renamed, or deprecated. 

> Did you understand that JEP-0115 is meant to be used only 
> in conjuction with disco#info?

Yes. I fully understand this. 

I get "Exodus. V0.9.0.0 EXT = A B C". in a presence packet. I then pick
3 random exodus users (that match the version) and send them disco
packets. The first client gets sent "Disco Get Node = 'Exodus V0.9.0.0
A'", the 2nd client gets sent "Disco Get Node = 'Exodus V0.9.0.0 B'" and
the third client gets sent "Disco Get Node = 'Exodus V0.9.0.0 C'". 

Each of these responses gets caches in my local disco cache. Hopefully
these responses correspond to Jabber Registrar items just as XHTML or
File Transfer. This is not spelled out in the JEP, but is (I think) a
good assumption on my part.

This means clients have significantly more complexity both as clients
and as Disco servers. A client needs to build a handler for each
feature, as well as support having the standard features the naked disco
info query. 

I couldn't find any two clients that, using this jep, were able to let
me do (or not do) file transfer or xhtml.

> > 4 - Stick with the Disco approach, but at least document all 
> > the features that can be looked for in a single place (The 
> > Jabber Registrar). Accept that this fails in many mobile and 
> > low-bandwidth cases due to the iq packet storm on login with 
> > a roster of any significant size.

> JEP-0115 was developed precisely to avoid this 
> "packet storm on login".

Agreed, it was. But I don't think it succeeded. 

On a small roster (say 10 items) with diversity among the client
contacts (which I suspect is the general case) this makes a large
increase in disco traffic ('cause it's one disco info request per
feature per client per version) rather than a decrease. 

Add into this equation the additional bandwidth of the client caps in
both presence and message stanzas and it's a big loss in quite a few use
cases. 

-- 
Chris Mullins




More information about the Standards mailing list