[Web-SIG] Session interface, v2
mso at oz.net
Sun Aug 21 03:08:37 CEST 2005
Ian Bicking wrote:
> Mike Orr wrote:
> I don't think several frameworks should share a single SessionManager
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
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,
>>> 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.
More information about the Web-SIG