Re: Distinguishing features and feature sets

At 07:05 04/02/99 -0800, Bill Newman wrote:
>I'm still a skeptic on using hash codes to stand for for feature sets.
>I still prefer using URLs, and letting high-performance servers do
>their own hashing/caching as necessary (through ordinary HTTP caching
>control).

Noted;  with the right components, I don't think the outcome has to
preclude this approach.  Maybe.

>> One motivation I see is that if SONY-GIZMO and ACME-COMMUNICATOR have the
>> same hash value, then they can be reasonably assumed to be the same feature
>> expression without actually knowing what that feature set is.
> 
>I'm not sure this is an important benefit.

I won't argue that this (alone) is of great importance.

>> Another motivation is that if a recipient's characteristics change, the
>> change can be detected without sending the entire feature set.
>
>I'm not convinced this is better than just having users set their own
>expiration times through HTTP cache control.

I have always felt that the idea of cache-timeouts is a slightly
unsatisfactory solution.  It works, most of the time, but an administrator
is left with a choice between setting a long timeout and sacrificing
responsiveness to change, or setting a short timeout and (potentially)
sacrificing bandwidth.  Hashes can overcome this by forcing a cache refresh
exactly when it is needed.

I observe:

(a) in the scheme of things, I think a 20-byte hash is quite small --
smaller than most URLs.  If a given hash is used more than once in a
message, and associated just once with a URL, the result might actually be
shorter.   (I am assuming a different approach here to that in some of my
recent postings.)

(b) despite the extra size, the use of hashes *might* actually decrease
network bandwidth usage through reduced cache refresh.  I do believe it is
more likely to reduce extra round-trips (see next point).

(c) I don't believe that any of what is being proposed here excludes the
use of HTTP caches in the way you suggest.  It may actually improve their
effectiveness by allowing longer cache timeouts to be set and reducing the
cache refresh rate when feature sets do not change.  Using hashes, any
change is detected immediately, so cache response to change is not an issue.

>... It also occurs to me that
>using a hash as an abbreviation to mess up the design goal you
>mentioned at one point, of supporting indirection to a central
>corporate profile which might change with time.

If true, I believe this would be a serious drawback.  I would like to
understand why you think this happens.

#g

------------
Graham Klyne
([email protected])