[Standards-JIG] Client Capabilities (rant)
chris.mullins at coversant.net
Sun Nov 20 19:28:08 UTC 2005
> Chris Mullins <chris.mullins at coversant.net>:
> > 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.
> When you spot CAPS in <presence/> packet you should remember
> it, perform normal DISCO features discovery and then cache
> the results under version+extensions combination.
Unfortunately you are not quite right. I don't perform normal disco
features discovery at all.
If I see 5 ext items in a presence packet, I need to make 5 disco info
requests (preferably scattered across 5 different physical clients, all
of the same version and type). These clients need to have special
handlers setup to understand the specific caps node that I'm performing
disco on, and need to return the appropriate disco info. This result is
hopefully an appropriate Jabber Registrar feature (although this is not
actually documented or shown in an example).
> Next time when you get the same version+extensions combination
> you would have the corresponding capablities discovered
> already in your cache.
I understand the JEP. The JEP and I are one. I am the JEP. The JEP is
Me. We are JEP.
... but I don't believe it solves the problem in the general case.
For the case of a large roster, with most or all users running the same
client version, it's a clear win. For all other use cases it's not a
win, and in some cases it's a large loss.
It does not serve to provide a general, efficient, mechanism by which a
number of client implementations and versions can exchange features.
... I'm also not ranting specifically about this JEP, but rather the
general state of inoperable client capabilities in general across the
popular XMPP clients.
More information about the Standards