[Standards-JIG] Client Capabilities (rant)
ian.paterson at clientside.co.uk
Mon Nov 21 23:28:07 UTC 2005
> Either the JEP needs to be changed,
> or this approach needs to not be used.
> Mixing and matching sections of various JEPs to piece
> together an ad-hoc mechanism for client capabilities is going
> to lead us further down the road to client incompatabilties.
The two methods are perfectly compatible.
Perhaps it is worth mentioning the alternative method in JEP-0115. It
would not break any existing implementations.
> This gives you a lot more traffic with modular clients. The
> whole point of ext is to be able to have many combinations of
> optional features in a client, without increasing the traffic
> much. In practice, if you have many extensions, you will
> almost never have the same node+ver+ext combinations, so you
> will get a lot of overhead if you don't query them separately.
I understand your point, but in practice I don't think it will be too
Even if a particular client has ten extensions, nobody will receive
presence stanzas with all 1024 possible combinations of those
extensions. You will probably only see ten different combinations.
Since most clients will typically have the default set of extensions
switched on, you might only need to send a single disco request instead
If there is only one example of a particular client version in your
roster then you will only need to make one disco request, even if the
client has many extensions.
A clever client could even minimise bandwidth by switching between the
two algorithms - depending on the number of combinations of extensions
it receives for each client version.
> I also thought about doing the persistent caching, because that
> seems to make a lot of sense, and can cut down on traffic even more.
Yes. It reduces the relevancy of all the above efficiency arguments.
Simplifying clients becomes the main issue.
More information about the Standards