[Web-SIG] Session interface
Chris McDonough
chrism at plope.com
Wed Aug 17 03:42:56 CEST 2005
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
>
More information about the Web-SIG
mailing list