Re: Event-driven document expiration

Shel Kaphan writes:
>
>Let me give an example.  Suppose you wish to create an interactive
>store that has a page indicating current user selections.  For various
>reasons, it is appropriate to implement this using server-side
>persistent state, and to allow the client to request the current
>version of this "current selections" resource at any time.

As an aside, it is almost never appropriate to implement such a concept
using server-side state.  It doesn't scale, it defeats caching, and it
results in a lot of unnecessary retrievals of the current state.  The
Netscape cookie mechanism has all but the first problem as well.

What should be done is define a market basket / shelf media type,
allow this type to be embedded in an HTML document, and let the client
implement its own methods of manipulating the items in the shelf
such that they can be dropped in their own basket.  The items could
then include sufficient information regarding payment mechanism and
cashier URL, such that the transaction of purchasing the items in
your market basket is simply a POST of that basket + payment info
to the cashier's URL, suitably encrypted and signed.

In this way, all but the last action is cacheable and the available
payment mechanisms are made clear prior to the user's purchase action.

>In any case, my prefered solution would be to use some response header
>to indicate the URI of the resource being returned.

That was already decided (for other reasons) at the HTTP-WG meeting
and is reflected in the new HTTP/1.0 draft 01 at

    http://www.ics.uci.edu/pub/ietf/http/
     ftp://www.ics.uci.edu/pub/ietf/http/
or
    http://www.w3.org/hypertext/WWW/Protocols/Overview.html

See the Location header.


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Sunday, 6 August 1995 12:49:07 UTC