I haven't been closely following this thread and this may have already been said but IMO sessions are most useful when the querying user is not identified and you need a place to stash data related to that user (e.g. a shopping cart). They are convenient in other cirumstances but rarely necessary.
I've never quite understood why people use server-side sessions for authentication. Maybe it's because they're typically so easy to use and have been sold as "the way to maintain state" in a web application to a lot of people. But in reality they can be quite expensive under high load because of their generality and there's almost always a better way. On Tue, 2005-08-16 at 17:42 -0400, Phillip J. Eby wrote: > At 05:08 PM 8/16/2005 -0400, Geoffrey Talvola wrote: > >Jonathan Ellis wrote: > > > Still, it can be good to have a simple place to store non-permanent > > > information. > > > >For example... > > > >I think a good use of sessions is in remembering selections that have been > >made earlier on. For example, suppose you have a reporting application > >where you allow the user to select one or more items to report on from a > >list box, several filtering options in dropdowns or checkboxes, sorting and > >grouping behavior, etc. You want to remember those settings so that if the > >user returns to the report selection page, their last selected settings are > >pre-selected. But, unless the user chooses to save those settings as a > >"stored report", you'd like to forget the settings when the user logs out or > >when they close their browser. > > > >Also, assume that your application already has this bundle of selections in > >the form of a Python object. > > > >Isn't the cleanest, easiest, and more efficient way to handle this to simply > >save the Python object in a session variable? > > No. :) > > I have to admit I'm probably biased by early Zope experience, where cookie > variables are as easy to use as form variables or any other kind of > variable. Just set the cookies to save the options, then refer to them in > the page. Sweet and simple. And if you set the cookie path to the path of > the page, then the client doesn't have to send them on every request, only > the ones where it makes a difference. > > > > In some cases, for example > >using Webware's in-memory sessions, for example, this data never has to be > >marshaled or leave the application server at all. > > > >If I didn't have sessions, I think using either cookies or a back-end db > >would be more work, less clean, and less efficient in this case. > > Maybe that's a limitation of the framework? As I said, I'm probably > spoiled by how easily Zope merges GET/POST/cookie variables, such that form > variables override cookies, but if the form variable isn't supplied the > cookie is used as a default. That one simple behavior made "smart forms" > really easy to make in Zope and Zope-like systems. > > _______________________________________________ > 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/chrism%40plope.com > _______________________________________________ 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