cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Continuations and the web
Date Mon, 24 Nov 2003 17:08:52 GMT

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 

> 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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message