[Standards-JIG] Client Capabilities (rant)
chris.mullins at coversant.net
Sun Nov 20 19:41:18 UTC 2005
> 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
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.
This means that, in case where I only have a single Exodus v0.9.9.9 user
on my roster, and he's announcing 10 ext values, I need to make 10 Disco
Info requests against that client.
> No. All features that are discoverable using Disco are
> also discoverable with CAPS (once the node+ver+ext
> combination exists in your Disco features cache).
The client I typically use, Pandion, support XHTML messaging. In fact it
supports it so well, there's no way I can turn it off.
Because it's an "always on" feature, the EXT node in the client
capabilities would not include "xhtml", right? It's not an optional
"In addition, the client MAY send an 'ext' attribute if it has one or
more feature bundles to advertise. A feature bundle is any non-standard
addition or extension to the core application, such as a client plugin."
In this case, the xhtml support in Pandion is not a feature bundle, a
non-standard plugin, or client plugin.
With 'xhtml' not listed in the EXT, I wouldn't disco the client and
check for it. Using this mechanism, I would never detect that Pandion
has support for xhtml.
More information about the Standards