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 <[EMAIL PROTECTED]> _______________________________________________ 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