Ian Bicking wrote:
>> At minimum, the SessionManager links the SessionStore, Session, and
>> application together. It can be generic, along with
>> loading/saving/locking. (Although we might allow the application to
>> choose a locking policy.)
>
>
> That could be a little difficult, since multiple applications may be
> sharing a session. But at the same time, applications that don't
> expect ConflictError are going to be pissed if you configure your
> system for optimistic locking.
>
> Of course, given a session ID and a session store, each application
> could have its own manager.
I wasn't thinking of multi-application sessions, much less whether they
would have their own SessionManagers. And since my applications don't
have a locking policy, I have no opinion which one is best, if you want
to impose one. Certainly it makes sense that applications sharing a
session must agree on a locking policy. I'd bias toward a common
SessionManager. Expecially to centralize the expiration. Should
applications sharing a session be allowed to have different expiration
policies? Perhaps SessionManager.delete_expired_sessions() is a good
thing after all.
Another limitation is the byte size of the session pickle. The
SessionStore knows this, and the SessionManager should make it available
to the application. Then the application (or launcher script) can raise
an exception at startup if it deems the size insufficient. None would
mean no limit, of course.
This happened to me when I was putting the entire result data in the
session, then imported a dataset with 3000 records. So "Browse All"
finds 3000 results... and that doesn't fit into a 65535-byte BLOB. The
database truncates the pickle, and behold, an obscure error at the next
request. I decided a larger session was ridiculous, and switched to
storing record IDs only. ("3000 ints is not an unreasonable size!")
> I was thinking of pythonweb's "Store":
> http://pythonweb.org/projects/webmodules/doc/0.5.3/html_multipage/lib/node153.html
>
>
> I vaguely suggest in the interface that each application should put
> all of its data in a single key (based on the application name). Now
> I think that should be based on a unique name (not the application
> name, because the application may exist multiple times in the
> process), and maybe with an entirely different manager.
Oooh, I haven't seen PythonWeb before. Well worth coordinating with, if
feasable. I wonder how hard it would be to port Quixote to
PythonWeb.... Seriously, they have a database-independent interactive
tool a la mysql/pgsql/sqlite3? "Wow, that's nifty." But a common
templating front-end?? "Get real. I choose a template engine for its
unique features, not the lowest common denominator."
>> Regarding sessionless persistence, that reminds me of a disagreement
>> I had with Titus in designing session2. Quixote provides
>> Session.user default None, but doesn't define what other values it
>> can have. I put a full-fledged User object with
>> username/group/permission info. Titus puts a string name and stores
>> everything else in his application database. So his *SessionStore
>> classes put the name in a VARCHAR column and didn't save the rest of
>> the session data. I argued that "most people will have a User
>> object, and they'll expect the entire Session to be pickled because
>> that's what PHP/Perl do." He relented, so the current *SessionStores
>> can be used either way.
>
>
> In the interface I suggest anything pickleable can go in a key. This
> requirement has been the source of some controversy in Webware, since
> people wanted to put open file objects and such in the session; mostly
> people coming from Java where apparently that's the norm. Anyway,
> it's still possible with this interface to have a store that never
> pickles anything; I can just hope no one writes code they expect
> anyone else to use that demands in-memory session storage. Those are
> lame even when you are using threads.
>
> I think the example shows one reason the session shouldn't be
> considered a public API. I think it's fine to put the username or the
> user object in the session -- we can debate the pluses and minuses,
> but it works -- but I think you should definitely wrap that
> implementation detail in something else. E.g., request.user should
> return request.session['user'] or something.
I'm not sure what you mean. There has to be a public API or the
application can't use the session. "Should I set an attribute or a key,
or call a method?" ("Coffee, tea, or milk?") There is no
request.user. Quixote has a get_user() function but it translates to
session.user. That's actually request.session.user but you're supposed
to pretend you don't know that. Or are you saying that applications
should not set attributes? In that case we might as well use a
dictionary as the official Session object, as Perl does. Of course
you'd have to put the metadata somewhere....
-- Mike Orr <mso at oz.net>