[Web-SIG] and now for something completely different!

[Chris McDonough]

On Thu, 2005-08-18 at 13:43 +1000, Rene Dudfield wrote:

> ... and now for all the arguments pro Session rolled up into one paragraph.
> 
> Taking load off the database server(with sessions) is a way to make an
> application more scalable.  

In my experience, they can make applications less scalable because
typically people don't need to know much about how sessions work so they
tend to overuse them without understanding their cost.  Very general
persistent session implementations that serialize object data into a
blob are typically even more expensive than simple relational database
row reads and writes, too.  This cost is amplified by session ease of
use.

> Often the database server is the
> bottleneck of the web app.  Being able to move some load to the
> client, or the webservers is a good option to have.

This is probably true for a lot of folks but my web apps are almost
always CPU bound at the web/application server.  I wish I had the
database-too-slow problem.

>   Being able to not
> use 2 tiers is also what people may want.  In this way sessions allow
> you to scale up, and down.  Sessions allow you to do a lot of jobs
> which databases are not needed for.

Typically persistent sessions are backed by some sort of database
anyway.  It's just that they're craftily coded in such a way that you
typically don't need to know much about it.

>   Sessions are also more reliable,
> and secure than cookies.
>  Cookies may not be enabled on the browser,

The most common way of enabling sessions is via cookies, and whether
sessions work reliably or not is often contingent on cookies.  Formvar
or URL-encoded session identifiers tend to be hit-and-miss and much
harder to maintain across pages.

> and storing some stuff on the client side in the clear, or even
> encrypted is dangerous.

I agree.  At least it's harder to get right.

>   Sessions are understood by a large amount of
> php/java/perl/apache people.  Lots of the python web frameworks have
> implemented sessions too.  This means sessions will be used.  So
> making a good working implementation of sessions that everyone can
> share would be double plus good.

What might be more practical and easier to think about because its scope
is so much smaller is a a common "browser identifier" implementation.

The most useful purpose of a session is to allow you to store state
across requests by some anonymous browser.  If you can reliably detect
that "the requesting browser is the browser identified by token ABC123"
and that token can be associated with the browser reliably for some
extended period of time, that's half the battle.  This can be done with
a cookie, a URL element, a form variable, or a query string element.
The association between an identifier and a browser doesn't really even
need to time out; it could live forever with no ill effect.

Creating namespaces that can be written to from within application code
and which expire after some number of minutes of inactivity and so forth
(aka sessions) could be written in terms of storing and retrieving data
based on this browser identifier.

- C