[Standards-JIG] Client Capabilities (rant)
hildjj at gmail.com
Tue Nov 22 16:15:42 UTC 2005
Perhaps the implementation notes section could say "please minimize
the number of ext's".
Note that multiple optional features could be bundled up. A client
writer could use this algorithm, which would mean that there would be
at most 2 info requests, but would mean that you would have to do the
second one much more often, at least for clients that are not identical:
1) assign each feature a unique small integer number, I(f)
2) mask = sum(1 << I(f))
3) ext = hex(mask)
I don't think I actually recommend this, by the way.
Putting the features in a registry in the sky was certainly
contemplated, but our experience with the version upgrade nonsense of
several years ago showed that we can't assume that clients have
outside connectivity. I assert that since the registry will change
over time, clients would have to look at the registry pretty
dynamically. We'd be right back to the same problem, but without the
ability to deploy in real-word situations.
On Nov 21, 2005, at 12:29 AM, Chris Mullins wrote:
> Maciek Niedzielski Wrote:
>>> but it doesn't really matter... if the version number
>>> is different, you still have to fetch their features
>> But this is only one query.
> Everyone keeps saying this. It's not what the JEP says.
> If it's a client that exposes 10 EXT items, and it's a client I either
> haven't seen before, or a version of a client I haven't seen before,
> then it's 11 disco requests.
> The JEP makes no guarantee that I can make a single disco request and
> get both the base node features, and the 10 explicit EXT node feature.
> Chris Mullins
More information about the Standards