Re: Transparency vs. Performance: survey of opinion

> 
> Larry Masinter writes:
>  > An issue that has been debated with vigor in the caching subgroup is
>  > one of of "transparency vs performance".
>  > 
> 
> I strongly believe that it is possible to come to a mutually
> satisfactory solution to this problem.
> 
> All the "you're wrong" accusations going back and forth are becoming
> just a tad repetitive. C'mon folks, this one isn't *that* hard to resolve!
> 
> Here is a very brief sketch of how this can be resolved.  It has
> already been suggested in part by several members of the caching sub-wg.
> I don't claim anyone agrees with this.  I'd just like us to get past this
> kid stuff.
> 
> 1. Semantic transparency is a good thing, and is necessary for certain
> applications to work.  We define "semantic transparency" to mean that
> the user perceives no significant(tm) difference in functionality,
> other than performance, when there are caches between the user and the
> origin server.
> 
> 2. Since users may occasionally need to override the default behavior
> of a browser for legitimate reasons, even though that may involve
> ignoring the wishes of a server application (or its programmer), we
> should allow this without calling it a violation of protocol.
> It's going to happen anyway.
> 
> 3. BUT: Clients SHOULD signal a server when the client may be ignoring
> the server's directives as to caching. Suggestions as to how this can
> be done are to introduce a new header (Cache-warning: <various
> options> (suggested by Koen)) or to use Jeff's Cache-control:
> stale-max=NNN (Roy's suggestion, though he wants to call it
> max-stale....whatever).  This will allow servers to take evasive
> action if clients inform them of their intent to live dangerously.

I think that server heuristics for stale objects should be activated
only upon user request. These heuristics can be defined or proposed
via cache metrics, and even the refresh of (some) cache objects could be
done spontaneously by the server, maybe anticipating requests. The
client should send a "Cache-control" header telling that the user
prefers performance over semantic transparency, and the server should 
send back a warning header if the requested object is known to be stale.

Nevertheless, I can't figure out how to tell the user "if you choose 
THIS browser option, you'll be perhaps not accessing the last version
of documents, but you'll have them sooner and quicker". And even then,
there are documents where the user will want to have the firsthand version
(like news headlines or weather reports), and others where a cached version
would be good enough. It would also be necessary to make the user aware
that one or more of the objects he's currently seeing on the screen
are stale.

> 
> 4. Clients SHOULD inform the user, and provide an option to
> reconfigure, if a server makes cache control requests that the client
> has been configured to ignore.  How to do this best is unresolved. This
> may be unworkable if the notifications are too frequent.  Perhaps one
> warning per server per UA activation...(I don't know).
> 
> 5. We should realize that not all clients will conform.  Twas ever
> thus.  Server application programmers must remain eternally vigilant.
> If we can figure a way to deliver electric shocks or post-hypnotic
> suggestions via the internet to people who program clients that way,
> that might help.
> 
> --Shel Kaphan
> 
> 
> 
Carlos

Received on Monday, 26 February 1996 06:07:49 UTC