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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
