W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Transparency vs. Performance: survey of opinion

From: Shel Kaphan <sjk@amazon.com>
Date: Sun, 25 Feb 1996 21:36:19 -0800
Message-Id: <199602260536.VAA11220@bert.amazon.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.

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
Received on Sunday, 25 February 1996 21:41:03 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:46 EDT