Stanczak Group <justin <at> stanczakgroup.com> writes: > > Good point. So far everything I've made uses Swing clients, so I haven't > really thought about the limitations of using cookies. I would have to > agree on the use of session. They shouldn't be included in Restlets. I > was always weary of using sessions in Servlets. Seemed like a lot of > people didn't mind just dropping anything in there, and most probably > just let whatever framework they use handle it. ...
The sessions we are talking about are not real sessions. Real sessions are not possible with current Web protocols. We can talk only about session surrogates. Because of this, when I hear cookies I am thinking "sessions" - support for cookies is already support for those faked sessions. And of course this is not the only way to fake sessions (but most popular). The problem is that, most likely, home-grown-cookies-based-sessions will be really bad - there is one big problem that strangely missing in this discussion. Security. Yes, there are problems with scalability, memory management - but these, as strange as it may sound, are not immediate problems. The security is. My position on this issue though comes not from technical considerations but rather from business ones. As this point the lack of any *good* support for what is called HTTP session will be very damaging for the Restlet framework. I cannot predict to what extent it can damage this baby, but it will be very damaging. This purism in its belief in what is right and what is not usually does not end up in great successes. This reminds me of the "prohibition" experiments in America. Guess what, if you think you can prohibit alcohol by changing constitution (because it's bad and people sometimes DUIs) - people are not going to listen to you even if it's in the constitution. Same way, arguments about HTTP sessions that are bad because people put there stuff that should never be there are just out of place and time. The devil is there, the rest (I like this game of words!) cannot ignore its existence. What will happen is that the actual experience will put the REST (and Restful framework) into perspective - the market will decide through its systems of opportunity costs whether it wants it or not. I would also like to point out that software engineers and Web developers will not be the only judges. You will also have project managers and security folks and, at the end, users. Serge
