Stefano Mazzocchi wrote:
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.
Yep, looks like some coins still need to fall.
On the other hand, invalidated continuations DO break the back-button.
Well, I do understand why some scripts are doing invalidations, just hoping we might be tempted to think about a better safety-net then the current 'continuation-has-expired-page'
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.
Mmm, dunno if I would give in at this point even.
Why can't we just look at the URL-with-continuation-ID as a dynamically created (and temporary available resource)? Then the only question is if those resources behave according to the ReSTy rules?
(and IMHO those rules are not really about a strict and complete state-transfer, are they?)
Hm. maybe I'm stretching the strict 'theory' into 'largely applying the filosophy', but in all cases I'ld like us to hold on to some level of pragmatism.
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.
at the limit this of course could mean that one needs to serialize over the state of the complete back-end database consulted from that continuation :-)
again, I don't really see how practical distributed computing could be arranged without any form of server side state... (which based on the loose coupling will require some kind of lease and invalidate mechanism)
AFAICS ReST is not ruling out that we do this, it is just advising us on how you do it?
just my 2c
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.
yes, in fact, since Godel we know that this applies to much more then only the web
(unfortunately the most blunt examples of mankind's 'my-right-way-based-cruelty' has been after the discovery of that)
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.
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
