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 _______________________________________________ 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