Re: Transparency vs. Performance: survey of opinion

On Sun, 25 Feb 1996, Daniel LaLiberte wrote:

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

Based on that assumption, there is no point in any of our work. Those
of us who disagree with Roy are not so naive as to believe the we can
force compliance, only that we should define failure to follow the 
server's direction as a non-conforming implementation. Further more, it
will be more difficult if not impossible to fault a server / application
which is conforming for any consequences of a user or client not 
following the protocol specification.

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

Most users rarely understand all the implications of the software they
use and obscure notions like caching.  Application implementors spend 
much more time checking out behaviors and are much better qualified to
make the judgements.

In any case, I believe a study of the caching subgroup archive would show
that all we have called for is clear carefully stated protocol elements,
which if the application conforms to HTTP/1.1, will be followed and
will deal with the issue. Roy has thus far refused to accept the 
requirement for such protocol specifications. Hence, it would seen you
really agree with Roy's opposition?

> clients that don't work well with what servers provide and require.
> So stop worrying about it.

If we don't worry about it, how will the users ever know?

Dave Morris

Received on Sunday, 25 February 1996 23:55:00 UTC