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".
 > 
 > Jeff Mogul summarized the sense of the subgroup as:
 > 
 > > 	Applications in which HTTP is used span a wide space
 > > 	of interaction styles.  For some of those applications,
 > > 	the origin server needs to impose strict controls on
 > > 	when and where values are cached, or else the application
 > > 	simply fails to work properly.

It simply can't be done, unless you want signatures on client
applications to verify they are approved software that obey the strict
controls.  Until then, clients can and will do whatever they please.  

 > To which Roy Fielding replied:
 > 
 > >   The reason that user agents are not always semantically transparent
 > >   is because the user does not always want them to be semantically
 > >   transparent.  No matter what is in the protocol, no decision by the
 > >   WG will ever change this fact of life.

I agree 100% with Roy.

Larry Masinter writes:
 > This seems to be a fundamental issue which affects many other parts of
 > the HTTP protocol with regard to caching, and unless we get beyond
 > this, we'll have trouble.

Yes, it is a fundamental issue.  This relates to the misunderstanding
some people seem to have that a URL such as "http://etc" means the
client will always use HTTP to resolve it.

The most we can ever do is provide protocol elements that allow
servers and clients to kindly *request* certain things of each other.
Servers cannot know that clients really are obeying a no-cache request
even if they say they are.  But users will tend to not want to use
clients that don't work well with what servers provide and require.
So stop worrying about it.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Sunday, 25 February 1996 20:38:25 UTC