[Standards-JIG] Client Capabilities (rant)
ian.paterson at clientside.co.uk
Mon Nov 21 10:00:12 UTC 2005
> 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?
More information about the Standards