At 06:08 PM 8/17/2005 -0700, Shannon -jj Behrens wrote: >I checked with a bunch of "really smart people" who are familiar with >a variety of Web technologies. I was worried that this idea "sessions >are considered evil" was widespread, and I didn't know about it.
Sadly, it's not widespread, any more than RESTful applications are, or object-publishing, or any of the other "the way the web was won" approaches to web applications. In the Java world, for example, it's just assumed that you have to apply tons of resources and trickery to scale your sessions, because that's just How Things Are. The reason it's How Things Are in Java-land is because Java made sessions part of their servlet and other specs right from the start -- a serious error that I was hoping we could avoid in Python-land. At least PHP gives you session management hooks that make it easy to put session data in the application database! It is, however, becoming gradually known in Java-land that the "physical three-tier model" is insane, and IMO that model is fairly closely related to the idea that you should store sessions in the web tier. I'd guess it's going to be a couple more years before "web tier sessions considered harmful" is known by any but the most cynical veterans of building high-volume, database-intensive applications, though. To be precise, what I object to are: 1. Web-tier sessions that store application data in a different database that may or may not be backed up, and may or may not even be a "decent" database 2. "bag of data" sessions that encourage people to throw arbitrary objects in there without thinking about what the information's real lifetime is. (If it's a preference, you want it to either persist on the client or the server, permanently. If it's credentials, you want it to time out on the client. If it's application state, you really need it in your database for integrity/synchronization reasons. If it's transient state like a status message, it doesn't belong in the DB, it belongs on the client. And so on.) So, given these principles, I don't see much need for a session manager besides client-state management, and a good O-R mapper. If you have those, then the rest is trivial. _______________________________________________ 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