At 01:14 PM 8/16/2005 -0700, Jonathan Ellis wrote: >Sure, sessions are overused and abused. Particularly among certain >classes of developers which I won't characterize here. :) > >But there's a reason they're in such common use; it's a huge waste >(particular for low-bandwidth clients) to store anything more than >absolutely necessary in a cookie that the client sends repeatedly. Much >more efficient to send "here's my token" which the server uses to >retrieve the rest.
I agree; and in fact until I saw Ian's status-message example, I've never had need to store anything in a cookie except login credentials or an identifier used to find application objects like a shopping cart. IOW, cookies are fundamentally for short strings. However, if your session data consists solely of short strings, or short-lived medium-size strings (like a status message) then it works out nicely. If you have session data other than short strings, then you should store it with your application data, since it's clearly data that's part of your application. There are plenty of object-relational solutions and you can select your transaction/locking policies to suit your application. You can then handle load balancing at the web tier without having to play session-affinity tricks at the load balancer. The last time I wrote apps using a session store was in 1997, which was also when I wrote a session store of my own as part of a Python ASP emulator. I quickly realized that session stores quickly become persistence systems in their own right, unless you draw the line somewhere. However, if you draw the line at identifiers and other short strings, then you can just draw the line at the client and avoid the whole problem. _______________________________________________ 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
