[8047] in www-talk@info.cern.ch
Re: Shopping baskets (was: Session tracking)
daemon@ATHENA.MIT.EDU (Dave Kristol)
Tue Apr 25 12:25:05 1995
Date: Tue, 25 Apr 1995 12:22:41 +0500
Errors-To: procmaster@www19.w3.org
Reply-To: dmk@allegra.att.com
From: dmk@allegra.att.com (Dave Kristol)
To: Multiple recipients of list <www-talk@www10.w3.org>
Paul Burchard <burchard@horizon.math.utah.edu> said:
> Marc Andreessen <marca@netscape.com> writes:
> > The cookie mechanism makes it trivially
> > easy for the server to generate the page that shows you
> > everything that's in your shopping basket (cardboard
> > box) and gives you all these functions at any time
>
> What puzzles me is -- why is the server involved in this at all?
> Why are we developing a complex stateful protocol to handle what
> amounts to the customer's private (until the final purchase decision
> is made) musings?
One reason for involving the server, and not the client, is that only
the server knows the nature and content of the information it's sending
out. Otherwise, each time a vendor discovers another interesting use
of WWW, it will either have to bend the application to fit existing
clients (still possibly true, I guess), or start shipping a custom,
special-purpose client.
Suppose I'm interested in the use of a Session-ID as a way to simplify
a magazine subscription service. The Session-ID constitutes (no
surprise) a way to track a "session", something you can't do easily
with a stateless protocol. In my case, it can track where you are in
the service hierarchy and that you've authenticated yourself. It can
also carry expiration information. I wouldn't want to have to wait
until all the client vendors had picked up the set of magazine
subscription extensions (along with the shopping basket extensions)
before I could offer such a service.
>
> 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...
[...]
It seems to me we have the choice of creating either client-side or
server-side kludges. Putting the kludges in the server makes the
software distribution problem simpler and makes it easier to start up
new services. All it takes is a little cooperation from a client.
Hence my earlier proposal for a very simple Session-ID mechanism, and
my general support for simple, general mechanisms in the protocol.
Dave Kristol
