Re: On transparency

Roy T. Fielding writes:
 > Jeff wrote:
 > 
 > > If the Web were simply composed of static (or slowly changing) documents,
 > > then the semantics of HTTP interactions would be trivial and one could
 > > easily let the user decide exactly what to do.  But this is manifestly
 > > not the only thing the Web is used for, and probably no longer even the
 > > most prevalent.  At the meeting on Feb. 2, for example, Shel Kaphan made
 > > it quite clear that the worst problem he faced in implementing his
 > > book-ordering service was the plethora of user-agent and cache
 > > implementations that blithely assumed they could decide when and
 > > when not to use a cached copy of some response.
 > 
 > Shel is wrong.  The problem is in his own application assuming that
 > the user will always want a stateful session.  There is nothing that the
 > working group can do to change the needs of people who use HTTP, and one
 > of those needs is to cache responses regardless of the nature of those
 > responses.  You may indeed define semantic transparency, and even require
 > that semantic transparency be the default behavior for caching applications,
 > but you cannot require that HTTP applications ignore the user's needs.
 > 

I can't go into all the ins and outs of why my application
required statefulness, and why the statefulness of part of the
application implied the need for statefulness in the whole
application.  I may suggest that you try building a shopping
application without it.  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).

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

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.

--Shel

Received on Saturday, 24 February 1996 18:28:43 UTC