On 23 Nov 2003, at 21:16, Tony Collen wrote:
There's a few interesting posts going on over at [1] regarding the use of continuations on web.
Continuations break the back button? bah.
I tried to set one of the people commenting straight on how it works in Cocoon, but they seems to be convinced it's being done all wrong. I think it's just due to their lack of understanding about exactly how Cocoon works.
In particular, post [2] is the most interesting (and ranty).
The guy has only one point there: a continuation ID is not fully RESTy. Agreed, it's not.
The only way to make this *really* REST-y is to pass the continuation (not the ID, the *ENTIRE* continuation) along with the response. This would allow complete replicability of the continuation.
But this is also a big security issue as the client has control on the state and could forge it.
I thought about this and I think it's possible to do a light form of encryption over the continuation so that the user can't forge it. The only required thing would be the same encryption key on the server side.
At the same time, requiring continuations to be serializable is a problem and moves the problem in another domain, doesn't really solve it.
Then again, that post is the author's opinion. The nice thing about the web is that there's no one "right way" to do anything.
The rest of what he says shows just how blind he is: a sitemap is just a decoupling layer. if you want to implement URL -> object direct mapping you can. nothing stops you from doing it.
I would be interested in investigating the whole "URL as accessing an object or an object's methods" idea though... much how Zope works.
big security danger: object injection and you are fucked. this is why I think you always need a decoupling layer, either from URL -> file or URL -> object.
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
