[Web-SIG] Session interface

[Phillip J. Eby]

At 12:02 PM 8/16/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>Session:
>>>    An instance of this represents one user/browser's session.
>>>SessionStore:
>>>    An instance of this represents the persistence mechanism.  This
>>>    is a functional component, not embodying any policy.
>>>SessionManager:
>>>    This is a container for sessions, and uses a SessionStore.  This
>>>    contains all the policy for loading, saving, locking, expiring
>>>    sessions.
>>
>>Which of these is responsible for managing client-side state?  (i.e. 
>>cookie reading, setting, expiration, and refresh?)
>
>SessionManager is responsible for expiration.  I'm not sure what you are 
>thinking of for refresh.  Updating last-accessed time?  That would be the 
>SessionManager as well.

By refresh, I mean updating a cookie's expiration time.


>   Cookies are not handled at all by these objects -- that's one of those 
> boring details I think is best left to library users (frameworks, 
> services, middleware), or put in another object.

Wow.  Those boring details, as you call them, are the entire concept of 
"session" to me.  Now that you've posted the right interface URL, I'm 
looking at it and not seeing anything there that seems related to what I 
think of as sessions.

To me, session management is totally about managing the client-side state, 
since anything I'm storing on the server is application state and just gets 
stored the way anything else does.  Some of the client-side state concerns:

  * Triggering actions when the state information isn't available (due to 
being a new sesssion or a client-side timeout)

  * Initial expiration vs. refresh policy

  * signed vs. unsigned data

If you handle these well, then simply storing real data in your application 
DB solves all problems, with no need for any of the objects in the 
interface you defined.

Or, to put it differently, I suppose I could wrap a pure client-side 
storage solution in the interfaces you propose, but it would be overkill, 
since concurrency would be a non-issue (among others).  It would also be 
slightly broken in that the interfaces you've written up don't deal with 
any of the *interesting* details, which (IMO) are all in the client-state 
policy areas.  (All the concurrency/scaling/cache-sharing/etc. issues of 
session stores vanish if you only have client-stored and db-stored data.)