At 05:08 PM 8/15/2005 -0500, Ian Bicking wrote: >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.
If I needed to do what you're doing on that page, I'd probably just put the message in a cookie, and reset it once it was used. In other words, a session isn't necessary just to have client-specific state, especially for something so short-lived as that example. > 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. The reason I enforce this particular discipline is specifically to *prevent* "random data" from being added *anywhere*. A session object that you can just throw any old data into is sloppy from my POV, because scaling most session backend systems well is a hard problem. If you are making a small-scale quick-and-dirty system, okay, whatever, but in the megahits/month range and up, I think session variable design needs to be much more systematic to ensure it can be scaled. Therefore, my philosophy is that every bit of client-specific state goes either in the application DB, or it goes in the browser. Anywhere in-between the two is a liability from my perspective, because it introduces a new tier that needs to be factored into design of the app's transaction model, scaling and reliability plans, etc. Ergo, there darn well better be a really good reason for introducing that extra tier. (And you'll notice the existence of this tier produces exactly the problems I know that it's "common wisdom" that sessions are supposed to be an important thing to have, especially since ASP and PHP provide them out of the box. (And at least PHP lets you implement the storage however you like!) But I view sessions of that kind with roughly the same disdain as I view Perl or Tcl's weak typing; they mask problems that I want to know about. I'm well aware that I'm in the minority on this point, but that doesn't mean I'm not still right. :) (And I'm also aware that "scaling down" is important, but the rule that all state goes either in the browser or the application DB scales down just as well as it scales up.) _______________________________________________ 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