[Web-SIG] Session interface, v2

[Mike Orr]

Ian Bicking wrote:

> Mike Orr wrote:
> I don't think several frameworks should share a single SessionManager 
> *instance*.  



Isn't that what being a session manager means?  The single gateway to 
the stores.  Otherwise it's more a case of two instances co-managing.  
That sounds more difficult, since the two managers may have different 
bugs and thus an unintentional difference in policy.


> class ISessionManager:
>
>>>
>>>     id = """The string-identifier for this session manager.
>>>
>>>     All applications that share this session manager need to use the
>>>     same id when creating the session manager.
>>>  
>>>
>>
>>
>> With this rule I was expecting some central repository of session 
>> managers, and factory functions a la logger.getLogger(), but there 
>> doesn't seem to be any.  What's the purpose of the SessionManager id?
>
>
> 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?


>>> 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.