Just to emphasize what Jeromy is saying, the key words are "scalable" and "cluster". In the case of an intranet application with a set user base that won't be clustered, *not* using session could be evil, since the alternatives tend to be more work to implement and maintain.
In physics, we have very different rules that apply for large-scale and small-scale calculations. We need to keep in mind that the same principle applies to web development. There are different rules for large-scale and small-scale deployments. Though, I do know large-scale deployments that do use session-state. In fact, they use *a lot* of session state, because, in their case, it's cheaper than going back to the database for everything. Of course, in this case, it's important to use a "sticky session" clustering approach that works. REST is cool, but I don't know how we'd use pure REST to write, say, an online banking system. :) -- HTH, Ted <http://www.husted.com/ted/blog/> On Nov 29, 2007 12:22 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Gary Affonso wrote: > > What's wrong with the session? > > > There's nothing wrong with it in most -existing- webapps because it's > the most productive means to record state, but it's always been a > problem for clustered apps, has always been evil according to REST > purists and is becoming less popular as web developers move to > SOAUI/SOFEA architectures. > > David Van Couvering's blog provides a good example: > http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html > > regards, > Jeromy Evans --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
