Re: session-id redux

Dave has some excellent points, made much more elegantly than I could 
have. :-)

On Thu, 27 Jul 1995, Dave Kristol wrote:
> Three points about Session-ID:

>     a) Clients provide a unique, but anonymous, identifier, so
> 	servers can recognize a given user and create a clicktrail.

But to stop at creating a clicktrail is "foolish".  What are people going 
to do with the clicktrail?  A write-only database is useless.  If people 
are going to use it for marketting analysis, that's something different 
than if someone's going to use it to show you different pages based on 
what advertisements you already looked at.

>     b) Servers create a Session-ID to keep track of a user's state.
> 	This state could be simply the path traversed through the
> 	document tree, or it could be a "market basket" of prospective
> 	purchases.

Yes, and until people start putting things in their "baskets" the server 
doesn't need to deal with session IDs.

> 2) The kind of Session-ID I have proposed, which the server initiates,
> does not lend itself to the client's returning one of its own choosing.

Right. If the clients can choose, you still need a mapping database.

> 3) I think server-initiated SIDs, as I've described them in (1b), are
[...]
> augment it.  I surely cannot get back from a caching proxy the document
> and SID that it handed off to the previous user.

Exactly.  They're basically part of the "Location" in URL.  That's why I 
think munging URLs isn't as bad as everyone else thinks.  The only 
difference between a "session-id" that really needs to come back from the 
client for the application to work and tacking it on the end of the URL 
(and setting it pragma: nocache or whatever) is that you don't have to 
edit the URLs on the fly at the server's end.

  --Darren

Received on Thursday, 27 July 1995 10:54:07 UTC