W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: Shopping baskets (was: Session tracking)

From: Gary Adams - Sun Microsystems Labs BOS <Gary.Adams@east.sun.com>
Date: Thu, 27 Apr 1995 09:51:53 -0400
Message-Id: <9504271351.AA14712@zeppo.East.Sun.COM>
To: www-talk@www10.w3.org, FisherM@is3.indy.tce.com

> From: Fisher Mark <FisherM@is3.indy.tce.com>
> Subject: Re: Shopping baskets (was: Session tracking)
> 
> >From what I understand, all we are talking about is passing an extra header 
> between server and client.  All a conforming HTTP server needs to do is when 
> it is passed the header by the client during a request, it should return 
> that header as part of the response.  Clients, meanwhile, after receiving 
> that header from a specific server, need to pass that header to that server 
> on subsequent requests.  The actual HTTP server code remains stateless while 
> clients gain only minimal statefulness (since the header value is a magic 
> cookie).  CGI scripts that use that header (the "stores"), are, however, 
> fully stateful.
> 
> >It's only the lack of serious client-side capabilities in today's
> >Web that's keeping you from thinking about this as the client-side
> >issue it naturally is.  Shouldn't we be devoting the effort
> >currently going into server-side kludges (I've done my share of
> >this) to improving the client capabilities?  From what I hear, Billy
> >G. understands and fully intends to exploit this weakness of the
> >Web...
> 
> Client-side capabilities should be expanded in my view (as you can see from 
> my previous postings).  The "magic cookie" approach requires minimal server 
> and client code changes, while enabling a new class of Web applications. 
>  Full, safe client-side scripting like that of Safe-Tcl's for mail will open 
> many new classes of Web applications.

Just to stretch the envelope a little further before the balloon bursts ...

Here's a simple workflow shopping basket scenario that might use a combination 
of cookies and hidden fields to accomplish a single complex ordering transaction.

Company A and B sign up for a collaborative project. Each compnay
will need to purchase some software and hardware from 2 or 3 vendors 
to get the project started. Let's assume that they share a secure 
means of transferring email and that they both have web enabled
mail applications on their desktops.

The project manager A.mgr1 constructs a document to cover the first
proposed purchases. The first additions to the document are for
the company B manager (B.mgr1) and company A's engineer (A.eng1).
As the document is wrapped up A.mgr1 clicks on the link which forwards
the contents of the document to A.engr1 like a routine slip.

Several links are added to the page for various vendors products
(C.prod1  D.prod2). Some products were linked in with special 
deals (C.prod2.reserved.1.2345 at C.prod2.promotion.price
valid til C.prod2.promotion.end_date).

When the engineer finished with the proposal, it was dutifully 
forwarded to B.mgr1 who repeats the process with B.engr1. Some
of the items were simply copied so that both companies would
be using the exact same products (except the prices were slightly 
different due to the timing of the orders and the local 
supplier ordering policies (e.g. $, , ).

After the final approval process, A.mgr1 and B.mgr1 make the final edits 
to the documents and each issue the purchase order for their 
relevant products.

This scenario would require some amount of state to be transported 
along with the document. Information identifying the various companies,
departments and employees would need to be maintained in a secure 
way. Some of the state would be stored at the vendor servers to keep track 
of reserved products or special pricing. Some state would be kept on
a clients workstation to keep track of document routing and intermediate
results of the larger transaction in progress.
Received on Thursday, 27 April 1995 09:52:05 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC