Re: Session tracking

Jared_Rhine@hmc.edu wrote:

> It could be argued that what I really want is your third goal:
> 
>   JP>    3) freely pass data as first class objects between client/servers 
> 
> but I think this is incorrect.  I don't really want to passing the state
> information back and forth all the time.  This information could get rather
> large, and if I have CPU cycles to burn, I'm willing to store the state
> server-side since it will improve performance, and that's of added value to
> my customers.

   I think we agree.  If the 'From:' field is widely used, you'd have what 
you wanted(1).  My point is that the protocol does not need to be changed to
handle session(1) &/or user identification(2) - WWW browsers/interfaces need 
to pass the right information.  Either way, the passing of an ID still needs 
to accompany each connection & this is exactly the reason I split this thread 
into three issues.  State information(3) is not just session(1) or ID(2)
information and needs to be handled differently.  Again, I think we agree, but 
until the interfaces do things as the protocol specifies, we are left with hacks.

Modified from my previous post:

   1) identify sessions (esp. from firewalled domains)
   2) enable unique, but changeable user identifications
   3) freely pass data as first class objects between client/servers

Received on Friday, 21 April 1995 18:53:12 UTC