[Standards-JIG] Client Capabilities (rant)

Ian Paterson ian.paterson at clientside.co.uk
Mon Nov 21 10:00:12 UTC 2005

Chris wrote:
> Ian wrote:
> > For each CAPS presence stanza you receive you check your
> > Disco features cache to see if you already have an entry 
> > under the node+ver+ext CAPS combination:
> > - If you have, then you use the cached Disco features.
> > (No Disco features discovery is necessary.)
> Agreed. This is clear in the JEP.
> > - Otherwise, you perform normal Disco features discovery,
> > and then cache the results under the node+ver+ext 
> > combination. 
> This is NOT what the JEP says. The JEP states:
> "... node that is constructed as follows: concatenate (1) 
> the value of the caps 'node' attribute, (2) the "#" 
> character, and (3) the version number specified in the 
> caps 'ver' attribute."
> This means that for each EXT that I see, I need to make a 
> Disco Info request against a randomly chosen client on my 
> roster that matches this exact client node/ext.

You do not need to include any node in your _single_ Disco Info request
(normal JEP-0030). So, even if JEP-0115 doesn't describe it, CAPS does
enable the algorithm above.

IMHO, for typical rosters, requesting Disco Info without a node for each
node+ver+ext combination received will result in slightly less requests
(more in some cases). The method requires more local storage. The real
benefit is vastly simplified client code.

If your client *fully* supports JEP-0115 then it will still have to
_respond_ to Disco Info requests that include nodes. IMHO that isn't too
onerous - although I confess I haven't implemented that bit of the JEP

JD Conley wrote:
> The assumption that Ian made about a single disco#info
> request certainly would make things simpler... Making
> separate requests to random contacts for each of the 
> EXT's just makes things way too complicated.

Yes, but AFAIK it isn't necessary even as the JEP stands. :-)

Perhaps I'm missing something?

- Ian

More information about the Standards mailing list