Re: Cache validators

>>    However, I am willing to give-in to that notion IF the opaque
>>    validator is sufficiently useful to cover the cost of sending it.
>>    That is, the opaque validator must be generally interoperable with
>>    existing systems and carry sufficient semantics for use for things
>>    other than cache updates.
> 
> First of all, the generally understood meaning of the word "opaque"
> is "has no meaning to clients", and therefore if you want the
> validator to carry other semantics, you're not talking about an
> "opaque" validator.

Actually, it means "can't see through it" -- it does not mean that
the string cannot hold a given set of semantics.  A validator is
worthless if it doesn't require some mechanism for comparing its
value independent of the source (e.g., byte-equality), since the
source cannot be contacted for all comparisons.

>>    In order to provide that additional usefulness, we need three things:
>>    
>>       1) A guarantee that the validator will change if the content changes
>>	  and should not change if the content remains the same;
>>       2) A guarantee that the validator is byte-comparable (i.e., equal
>>	  validators mean equal content);
>>       3) A guarantee that the validator is world-unique.
>>    
>>    (1) is obvious.
> 
> Not necessarily.  To be useful as a cache validator (unburdened
> by any other semantics), it is sufficient that the value changes
> if the content is semantically different.  It is not necessary
> that the value change on every insignificant change in the content
> (where "significant" is defined by the application that generates
> the content).

I said "additional usefulness".  The particular additional usefulness
I have in mind is for a basic indicator of change which would be usable
for preconditions [i.e., the most often used precondition is
"don't do this if a change has already been made that I don't know about"].
Dual application reduces the cost of implementing both, and I personally
need this functionality more than I need transparent caching.

Since it is unlikely that anyone will ever implement a system which
only changes the validator for "significant" changes, I think it
would be silly to lose the additional functionality gained from a
guaranteed change indicator.

Note also that if we have (1) and (2), we also have a clear algorithm for
constructing a unique ID identical to Content-ID, which would be
useful for gateways and cache tables even if we don't use the Content-ID
syntax of MIME [because we get (3) by combining the validator with the
Request-URI].


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Sunday, 10 March 1996 22:59:02 UTC