[Standards] Entity Capabilities Woes

[Rachel Blackman]

>> Would be the same for most cases - but from protocol point of  
>> view : it
>> need not necessarily be the same.
>> Hence, we cache it as a tuple of all three and dont assume that it is
>> same across versions.
>
> That's what we do as well. But on the other hand, if you can assume
> it, you can cache it by a mapping from disco node
> (http://psi-im.org/caps#0.11, http://psi-im.org/caps#cs) to features,
> making it even easier to implement (and avoiding even more disco
> requests).

I actually cache via the exts, since the XEP strongly implied that  
once defined, a capsnode#ext result shouldn't change.  If people have  
been implementing it the other way, I may change it to caching by  
tuples, but this seems like a best-practices matter again.  If you  
change your ext meaning, you run the risk that people have already  
cached a different version.

As for sending, having everything cached on disco nodes makes it easy  
to handle responses, too.  In the cache I pre-populate all of my own  
capsnode#ver and capsnode#ext results (so they use the same code if I  
spot another of my own caps bits) marked with a 'local' flag.  If I  
get a query for a disco node that I don't handle somewhere else, I  
just check the cached results, and if there's one matching that node  
marked 'local' I send it back.  And when I get a node-less disco  
query, I go to the cached stuff and just grab any featureset with  
that 'local' flag set and return the union of them all.

So I don't have two separate sets of results to keep in sync if I add  
a feature; if I add a feature to my root set or add an ext, the node- 
less disco automatically picks it up.

I admit, I'm not certain my implementation /is/ best-case.  My logic  
goes something like:

1) They support caps, use that.  Query and cache as necessary when we  
get presence.  (Or if we get a message stanza from an off-roster  
contact, containing caps bits.)
2) They don't support caps, so if we need to interact with them try a  
node-less disco.
3) They don't support nodeless disco and we're still trying to talk  
to them, so do an iq:version and use that to get some psuedo-disco  
results I've also coded into the cache.  (Basically, translate into  
'legacy:<client>:<version>' for the nodeid, and try looking that up  
in the cache.)
4) Give up.  They ain't going to give me anything to go on, go weep  
in a corner at how we need client certification to keep adoption of  
new protocol moving, and in the meantime simply assume that if they  
don't support disco, they probably don't support anything.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/