[Web-SIG] and now for something completely different!

[mso@oz.net]

Phillip J. Eby wrote:
> So I'd personally prefer that any session service standards distinguish
> between management of the session itself, from storage of data associated
> with the session.

Yes, but the web-sig needs to define both APIs, and encourage generic
implementations of both.  Otherwise every framework or every user has to
write their own storage backends.  Speaking from experience with Quixote,
which has no persistent sessions out of the box.

Also, the serialization method(s) need to be documented.  That's a
property of the storage object.  All existing ones I know of use pickle
(sometimes encapsulated by Durus or shelve), but that may not be the case
forever.  Plus there's pickle vs cPickle; I've heard the latter has
Unicode problems.

> Of course, I personally prefer to use whatever the application's storage
> is for my session management

That's what I've been doing too.  session2 is made to play nicely with
your application's database, sticking to whatever table you designate for
it.

> To put it another way: I don't believe in session variables,
> only session-specific application objects.  An ecommerce application
> should
> have persistent carts and items and the like; the only purpose of a
> session
> is to find out which cart to look at.

We already have some frameworks with dict-like sessions and others with a
standard session object.  Assuming we had a hybrid object that accepts
both, I don't know why any application *has* to have a custom session
object.  But there's no reason to arbitrarily preclude it either.

> Indeed, I'd argue
> that applications that *don't* put their session data in the application's
> main DB should have very very good reasons for doing so, and I've never
> heard a good enough reason yet.

Ian Bicking wrote:
> There's useful reasons for non-application code to store things in the
> session, and the particulars of the application storage aren't really
> applicable.  For instance, with this pattern:
> http://blog.ianbicking.org/web-application-patterns-status-notification.html
> -- you put transient messages in the session.  But there's no point to
> using a fancy application session storage which means documentation and
> configuration and whatnot.  Maybe you have no impediments to throwing
> random data into your application data stores, but I do.

I wouldn't call that example "non-application" code.  Setting a message in
the session for the subsequent request to display is very useful.  "Record
added", "Add cancelled", "logged out", etc.  I'm not sure third-party code
(middleware) should be able to add a message directly, but that may turn
out to be a significant feature of certain middleware.

-- 
-- Mike Orr <mso at oz.net>