[Standards] Entity Capabilities Woes
rcb at ceruleanstudios.com
Thu Mar 15 16:38:45 UTC 2007
>> 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
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
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/
More information about the Standards