Re: Session tracking

On Apr 18, 11:06pm, Thomas Maslen wrote:
> Subject: Re: Session tracking
> Could I ask people participating in this thread to outline the scenarios
> that they're thinking of when proposing session-tracking machinery?
>
> Brian did this well in his message that started the thread;  he's interested
> in tracking "clickstreams" (first time I'd heard _that_ term...).  Thus he
> wants a session-id that identifies a single session but doesn't (I think)
> need to maintain state between sessions at different times for the same user.
>
> I'm not sure whether Lou's proposal is meant to solve the same problem or a
> larger/different one.
>

My proposal is meant to solve a much broader set of problems than
a simple session id.  The "Cookie" idea allows the server to
save state information within the client for use in a broad
class of applications.  One of it's more useful applications
is an online shopping basket.  While shopping, the server
can place tokens within the client's cookie mechanism to
represent items that the user wants to buy, when the user
wants to "checkout" they simply go to a cgi script that
digests all the cookie information and assembles a
price/receipt/shipping information/etc.  If you try
to use documents or URL's to hold such information you
inevitably get errors due to the user hitting the
back button or reload or any other out of order
navigation method.  Using a cookie there can be no
confusion since the state isn't tied to the URL or
a particular document.

By using a "realm" concept through the use of path
mappings the cookie proposal allows multiple cgi
applications running on the same server to each
have a seperate and private cookie, this allows
for multiple non-interacting applications running
on one server and a higher degree of privacy.

:lou



-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 19 April 1995 15:34:33 UTC