After Graham Glass, here comes another old Java hand diving into Ruby on Rails.
Elliotte Rusty Harold: “I tried writing some PHP pages, but that was more difficult than I expected so I thought I’d take a day and see if Ruby on Rails was all it was cracked up to be. I’d looked at it initially, but decided against it because IBiblio doesn’t yet support Ruby. But I’m prototyping this on my desktop Mac, and if Ruby makes my job a lot easier, I could find a different host.”
I will follow this development with lots of attention, but already the following snippet raised my alarm sensors:
It’s trying to set a cookie for no reason whatsoever, even for a page that doesn’t exist! What’s worse, it’s a session ID! This is completely contrary to the web architecture, and a very common mistake made by developers who are mired in 1980s style of applications and have never understood the Web, and probably never will. My PHP version and the existing site I’m replacing are completely cookie-free. This is not a good sign, and does not leave me with a warm-and-fuzzy feeling; but let’s deny the setting of the cookie, proceed onward, and see what happens.
Can this be true? I’d like to know. Looks like this will be soon, as while I was writing this the bell rang: It’s my new Ruby and Rails books! Looks like my productivity might drop just a little bit in the coming days ;).
Agylen 
By default every controller will create a session unless you explicitly specify that a controller should not.
Regardless of the “philosophy of the web” most webapps still use session state. This goes hand in hand with the aggressive use of “sensible defaults” in Rails. Since most webapps use a session it is the default, if you at a later stage find you don’t need the session you can always turn it off by explicitly overriding the default (on a controller local or application global basis).