You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tony Collen <co...@umn.edu> on 2003/11/23 21:16:20 UTC
Continuations and the web
There's a few interesting posts going on over at [1] regarding the use
of continuations on web.
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).
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.
I would be interested in investigating the whole "URL as accessing an
object or an object's methods" idea though... much how Zope works.
Thoughts?
Tony
[1]
http://www.manageability.org/blog/stuff/web-based-continuations/talkback/1069462964
[2]
http://www.manageability.org/blog/stuff/web-based-continuations/talkback/1069607372/discussionitem_view
Re: Continuations and the web
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 18:08, Marc Portier wrote:
>> 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 :-)
very very very true. Keep in mind that REST is just a research paper,
there is no evidence that pure REST can work in the real world as REST
tends to ignore bandwidth usage and security.
> 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)
"practical" is the key word here, I absolutely agree.
> AFAICS ReST is not ruling out that we do this, it is just advising us
> on how you do it?
REST is, more than anything, a philosophy becoming a techy buzzword. I
think it's almost impossible to write a practical and secure pure REST
web application in the real world.
At the same time, it's good to keep an eye on it as it gives you a
metric to understand how distant you are from the optimal lack of state
preservation vs. state transfert.
--
Stefano.
Re: Continuations and the web
Posted by Marc Portier <mp...@outerthought.org>.
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/
mpo@outerthought.org mpo@apache.org
Re: Continuations and the web
Posted by Ugo Cei <u....@cbim.it>.
Leszek Gawron wrote:
> I have also a problem that maybe the same: How should one protect the
> application from resubmitting the previous continuation? If user hits back
> button and submits again the the form gets into inconsistent state (some
> action gets called twice).
var kont = cocoon.sendPageAndWait(...);
kont.invalidate();
> As some woody actions get executed automatically
> (adding a repeater row for example) there is no way to prevent this.
In that case, doing a resubmit would trigger another insert. If you see
a problem with whis, there might be a way to invalidate that
continuation, but I haven't looked deeply into this.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Continuations and the web
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 17:06, Leszek Gawron wrote:
> On Mon, Nov 24, 2003 at 04:55:50PM +0100, 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.
> I have also a problem that maybe the same: How should one protect the
> application from resubmitting the previous continuation?
you invalidate it in your flow.
> If user hits back
> button and submits again the the form gets into inconsistent state
> (some
> action gets called twice). As some woody actions get executed
> automatically
> (adding a repeater row for example) there is no way to prevent this.
Hmmm, don't know enough about woody to answer this. Bruno? Sylvain?
>
> This is all due to the fact that continuation stores only point of
> execution
> and just shares the data model.
>
>> 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.
> I've tried to use WebForms (.NET) - in there all controls' data and
> state is
> being stored in one huuuuuuuuuuuuuuuuuge input hidden field.
Really? is that a session or a continuation?
--
Stefano.
Re: Continuations and the web
Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Nov 24, 2003 at 04:55:50PM +0100, 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.
I have also a problem that maybe the same: How should one protect the
application from resubmitting the previous continuation? If user hits back
button and submits again the the form gets into inconsistent state (some
action gets called twice). As some woody actions get executed automatically
(adding a repeater row for example) there is no way to prevent this.
This is all due to the fact that continuation stores only point of execution
and just shares the data model.
> 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.
I've tried to use WebForms (.NET) - in there all controls' data and state is
being stored in one huuuuuuuuuuuuuuuuuge input hidden field.
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: Continuations and the web
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
RE: Continuations and the web
Posted by Reinhard Poetz <re...@apache.org>.
From: Tony Collen
> There's a few interesting posts going on over at [1]
> regarding the use
> of continuations on web.
>
> 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).
Find my comments on his posting:
http://www.manageability.org/blog/stuff/web-based-continuations/talkback
/1069663976/discussionitem_view
BTW, I don't like his wording in some parts (e.g. "legitimate use") but
as I want to learn more how others implement their applications going
the RESTish way I decided to reply.
--
Reinhard
> 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.
>
> I would be interested in investigating the whole "URL as accessing an
> object or an object's methods" idea though... much how Zope works.
>
> Thoughts?
>
> Tony
>
>
> [1]
> http://www.manageability.org/blog/stuff/web-based-continuation
> s/talkback/1069462964
>
> [2]
> http://www.manageability.org/blog/stuff/web-based-continuations/
> talkback/1069607372/discussionitem_view