[Standards-JIG] Client Capabilities (rant)

Joe Hildebrand 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
>>> anyway.
>
>> 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 mailing list