Re: Distinguishing features and feature sets

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).

> At 12:56 03/02/99 -0500, Al Gilman wrote:
> [...]
> >The lazy client that doesn't want to dereference ACME-COMMUNICATOR will
> >match it with ACME-COMMUNICATOR and treat ACME-COMMUNICATOR and SONY-GIZMO
> >as values of different tags.  The industrious client will dereference
> >ACME-COMMUNICATOR and know it matches SONY-GIZMO or the content of
> SONY-GIZMO.
> >Yes?
> >
> >I guess I just missed an earlier turn in the road -- like the motivation
> >for hashes.
> 
> 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. If we just use ordinary
HTTP caching control, then writing X to designate whatever the
characteristic time for flushing the server's cache is, this saves
only one fetch per X. (After one fetch, the server realizes that the
two are the same.)

Meanwhile there's also an extra cost for hashing approaches. Depending
on the detailed approach chosen..
  (1) If only hash is sent on every request, then if there's a cache
      miss, we need an extra round trip between client and server 
      (necessarily over a wireless link for a mobile client) in order
      to retrieve the full resource.
  (1) If both hash and URL are sent on every request, then the extra
      round trip can go over a land line (good) but we pay the extra
      overhead of some 20 hash bytes sent for every negotiation.

> 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. 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.

> An underlying motivation here is to save bandwidth whenever possible.  As
> Ted pointed out, look what happened to HTTP Accept: headers because the
> information to be communicated (repeatedly) became too voluminous.

I do agree completely with this, and add that by and large they were
transmitted over stationary links (14.4kbaud or faster) not mobile
links (for which 14.4kbaud is fairly fast).

  Bill Newman
  [email protected]