Phillip J. Eby wrote: > Of course, I personally prefer to use whatever the application's storage > is for my session management, so I'll probably have little reason to get > involved in the "storage" side of the session equation. 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. :) Well, there's, "my > application's DB suxors", but that means you ought to upgrade the > application DB instead if you can. :)
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 think there's quite a few other use cases for this same kind of thing which I think implies that there should be a standard generic location to store session information. Or you can ignore that and use the session ID only. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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