Re: On transparency

> The problems I encountered were precisely in
> those parts of the system that most required stateful behavior, and
> those problems turned up in testing the user interface with real
> users, not protocol designers. We found that no matter how we set
> things up, there are certain caching-related issues (esp. as it
> relates to history functions) that are exposed at the user interface
> and that confuse people.  It doesn't have to be this way, but the
> current state of the protocol, and assumptions made by browser
> implementers, make it this way.  (Actually, if browsers really obeyed
> the spec and history mechanisms weren't conflated with caches to the
> current extent, it would all be much more straightforward, though that
> is not the full extent of the problems).

I know that -- I did read your initial paper.  All of the identified
problems are solved in the HTTP/1.1 spec *if* the client wants them
to be solved.  In other words, the protocol allows the server to
completely describe its needs to the client.  The protocol does not
require them to be obeyed, because to do so would be to require that
the user agent make a request even when the user does not want it to.
Since requests sometimes cost the user money, that would be a major problem.

Browser authors will try to do whatever they can to ensure that the
user can do what they want, regardless of what the HTTP specification
says.  After that has been achieved, they will (hopefully) try to do
what is wanted in the most interoperable way, which is (hopefully) the
way described in the HTTP specification.

> If you take the position that HTTP just shouldn't be used for
> applications that don't fit into what the original browser
> applications provide (much of which is not defined by the protocol),
> or that the casual user always knows better than the service author
> the details of how the browser should behave, you're just saying that,
> according to you, certain types of applications should not be built.

Yes, some types of applications should not be built, and other types
of applications should be built but cannot assume that they will always
be used the way the creator thinks they should.  That's life.

> In the face of all the activity and creative energy focussed on the
> web these days, this position is simply untenable.  People (which
> includes service authors) will find a way to get done what they need
> to get done.  It would be better if the protocol and browser authors
> made that easy, but if they don't understand the issues and
> requirements, we're doomed to a future of ridiculous workarounds just
> like it's always been.

Progress is made one implementation at a time.

> That said, I don't object to there being controls on browsers that
> supersede the default behavior when the user has a special requirement.
> I'd prefer if the non-default mode were graphically displayed 
> (perhaps a good application of <blink>) so that people would have a
> clue why things might not be working in certain applications.
> But to say that in all cases, the user knows better than the service
> author how caching should work and how it should interact with history
> mechanisms is way too extreme a statement.

But to say that, in all cases, the service author knows better than
the user what the user's requirements are is also ridiculous.  The reason
why the user is given more power is because the user is responsible for
making the decision that results in the network request, which means
the user may be responsible for the costs of that request, which means
the user must be in complete control of that request.  Providing the
user with more information upon which to make their decision is
certainly worthwhile.


 ...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, 25 February 1996 11:57:37 UTC