- From: Gary Adams - Sun Microsystems Labs BOS <Gary.Adams@east.sun.com>
- Date: Thu, 27 Apr 1995 09:51:53 -0400
- 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