[Web-SIG] Session interface, v2

[Ian Bicking]

Mike Orr wrote:
>> The session manager id is used by the session store, to keep the 
>> sessions separate.  Actual session data is keyed by 
>> (session_manager_id, session_id), so that separate applications have 
>> separate session_manager_ids, and separate browsers have separate 
>> session_ids.
> 
> 
> 
> 
> OK, we're using different terminology for the same thing.  I would call 
> that an application ID.  Two applications that want to share sessions 
> would use the same ID, and two instances of a blogging application that 
> don't want to share would have different app IDs   MySQLSessionStore has 
> an app ID in the constructor, and the session is saved under (app_id, 
> session_id).  It defaults to '' if you only have one application and are 
> too lazy to make up a name.
> 
> Calling it app_id seems to make more sense.  The user would find it 
> logical to have to name their applications (=session namespaces).  
> Whereas naming "session managers" sounds like an obscure implementation 
> detail not related to this.  I would think a session manager ID is its 
> memory address, and why on earth would we want to know that?

The session manager needs to be instantiated with the app id, and we 
could rename it there, yes.  It doesn't really matter to me.

>>>> class ISessionStore:
>>>>      def load_session(session_store_id, session_id, read_only,
>>>> session_factory):
>>>>      def session_ids(session_store_id):
>>>>      def delete_session(session_store_id, session_id):
>>>>      def touch(session_store_id, session_id):
>>>>      def write_lock_session(session_store_id, session_id):
>>>
>>>
>>>
>>>
>>> Isn't session_store_id 'self'?  Specifying it seems to imply this is 
>>> a meta SessionStore, not an individual store.  Why would a deployment 
>>> have multiple stores?
>>
>>
>>
>> Oops, this was a leftover from when SessionManager was named 
>> SessionStore.  These should all be session_manager_id.  Fixed in svn.
> 
> 
> 
> OK, translating 'session_manager_id' to 'app_id', this almost makes 
> sense.  So a SessionStore instance can handle multiple applications. Is 
> this likely?  I'd like to find some way to avoid passing this value to 
> every method, since from the application's perspective, there's only one 
> that matters.

The session manager embodies that context, so you never pass that 
around.  The session manager also has the locking policy; as you noticed 
you don't want optimistic locking unless you are ready for 
ConflictErrors, and you don't want lossy if you are relying on the 
session for something important.  So application's shouldn't share that 
setting either.  The SessionStore interface is fairly dumb about what 
it's storing, so it should be able to support multiple policies 
simultaneously.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org