[Web-SIG] Session interface

[Phillip J. Eby]

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.