[Web-SIG] Session interface

[Chris McDonough]

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 at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com
>