You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@xemacs.org> on 2002/02/01 03:51:02 UTC
Re: first impressions on continuations idea
Hi Allan,
[I've Cc-ed cocoon-dev, as I believe you bring up some good points.]
On Fri, 1 Feb 2002 00:32:50 -0000, Allan Erskine <a....@cs.ucl.ac.uk> wrote:
> Sorry this has been long in coming - it's really busy for me right now.
No problem, it's been busy for me too.
> But I've made my way through the papers you sent, and the relevant
> threads - I really love it.
I loved it too when I saw it the first time ;-)
> For a start it plain old smacks of a good idea - anyone who's suffered
> the indignity of having to code a web-app must surely weep at the
> concise flow programs in Queinnec's papers.
I definitely agree with you.
> Secondly I love the idea that we can start to use higher-order language
> features throughout the web-app development process. Instead of
> HTML/XML/validation code/backend code/actions which is just
> unmanageable.
Yes, it's just a pain to do this, and Cocoon and all the other
frameworks really suck in this respect.
> So I'd be really interested in what you plan to do with this schecoon
> web-app example.
>
> Starting with the example code you put up on cocoon-dev:
>
> Ovidiu said:
> >
> > Because of the continuations, the URLs for the second and third pages
> > would probably look more like:
> >
> > http://foo.com/add/4ffds8454mfd90
>
> Would a session not be the appropriate place to store continuations and
> associated data? The URL strikes me as a really bad idea, as it should
> be a logic-level address (ie foo.com/add) rather than an implementation
> level (foo.com/add/4ff.) Under what circumstances might you wish not to
> resort to session?
This is a good question.
If you look at the concept of session in the servlet environment, you
realize it's only a way to save state across HTTP requests. But with
continuations, you no longer need this! The continuation saves in it
the complete stack frame of calls, including local variables. When a
continuation is resurrected, it will contain the values for all the
local variables you declare.
What you're referring to is probably not session, but cookies. The
problem is you cannot use cookies to encode the continuation's URL, as
this would prevent the user from hitting the back button. This happens
because the cookie is set globally, for the whole domain. Hitting the
back button will not change the cookie's value to point to the right
page.
So clearly you need a way to encode the continuation's URL in the page
itself, rather than assign it to a cookie.
Now if you do this, on the server side you need a way to extract the
continuation's id from the request, obtain the continuation and invoke
it. Rather than imposing a fixed URL scheme, I now believe the task of
identifying the continuation's id should be left to the sitemap. A
sitemap admin could map continuations to different URLs, to fit the
general look of the URL on that site. Something like this:
<map:match pattern="continue/(.*)">
<map:call function=invoke-continuation">
<map:parameter name="id" value="{1}"/>
</map:call>
</map:match>
"invoke-continuation" is a special function which takes a continuation
id, determines the continuation, and invokes it, effectively
restarting the processing.
> Ovidiu said:
>
> > You can then mount each function at different URLs:
> >
> > http://foo.com/first/
>
> Just checking - you'd intend this to be mapped automatically from the
> function name?
No, it's also based on the sitemap. Check-out the current sitemap in
schecoon, to see how this is done:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/schecoon/webapp/sitemap.xmap?rev=1.2&content-type=text/vnd.viewcvs-markup
> Ovidiu said:
>
> > send-page("show-shopping-cart.xml");
> > operation = request.getParameter("operation");
> > if (operation == "continue-shopping")
> > send-page("continue-shopping");
> > else if (operation == "buy")
> > buy();
> > else if (operation == "update-quantities")
> > update-quantities();
>
> I realise this was just a first attempt to demonstrate a Javascript like
> language, but the sort of code above is going to appear _all_ the time.
> And it is loosely cohesive too, since presumably in
> show-shopping-cart.xml there are magically-named fields corresponding to
> the operations "continue-shopping".
>
> Surely it would be much nicer to have each page defined as a first-class
> entity + operations _within_ your flow-language. Encourage the OO
> style, e.g. this sort of thing
>
> Class customer {
> IDType ID;
> String name;
> String address;
> }
>
> class Cart {
> customer c;
> order_goods gs;
> }
>
> //class page is predefined, included reflecting show method
>
> class Cart_page : page {
> Cart c;
> buy() { new Checkout_page(c).show() }
> continue_shopping() { new Shopping_page(c).show() }
> .
> }
>
> With the continuation handling stuff in the predefined show() methods.
> All the xml would be generated automagically. Code-generators could
> also be written for various backend solutions. There are plenty of
> object-models available out there for scheme. All you'd have to write
> would be the transforming code.
I'm sure this would be an option for us, programmers, but Web page
designers would probably still want their HTML/XML pages.
I believe the send-page(xml-filename, pipeline-name, data-dictionary)
makes for a more separation between flow, logic and presentation.
> Ovidiu said:
>
> > Also I don't like to express logic in XML, it's not what it was
> > designed for. We need a programming language, so why use an XML syntax
> > to express this? The attempts to use XML to implement a programming
> > language are taking XML too far, where it wasn't designed to work.
> >
> > --
> >
> > I think with the new model, there's no need for actions, redirects and
> > other things that the sitemap currently has. They are no longer needed
> > as you have full control over what's going on in your application at
> > the program level. And you can control your application in a much
> > better way than before.
> >
> > In the new model, the sitemap becomes a dispatcher to either a
> > pipeline, or to a function in our language with implicit continuations
> > (any good name for it?).
>
> All this is what I like best. It will let C2 return to what it's good
> at. The poor old sitemap is groaning under the stress. And actions are
> *@#$!
Yep!
> So what would be the first step? A flow-program generator for the
> schecoon sitemap?
Right now I have a simple XML sitemap implementation written entirely
in Scheme. It allows me to specify:
- matchers that contain simple pipelines, that contain either of
these:
- generator transformer* serializer
- reader
- call resource
- call a Scheme function
- resources: these are simple pipeline definitions, which have a name
associated with them.
The Scheme implementation reads an XML sitemap and translates it into
Scheme code. The resources are translated to Scheme functions, so
calling a resource is nothing else than calling a Scheme function
(read very fast, possibly faster than today's compiled sitemap
approach, though I didn't test it yet).
You can declare Scheme functions to be called from the sitemap. These
functions are defined in a special way, which allows the sitemap to
pass named arguments, without having to be worried about their
position as formal arguments of the Scheme function.
The next step is to implement the mechanism for storing continuations,
identifying them, and invoking them on request. This should be easy to
do. Once this last step is done, you can start writing flow programs
in Scheme!
The last step is to write a translator from a more friendly language
to Scheme. This is the hardest part, as I'm not sure what features
this language needs to have. I'm trying to decide on this, and
prototype a little bit with it.
As a showcase for the new Cocoon architecture, I'm thinking to take
the J2EE PetStore application and rewrite it with Cocoon's flow
support. A colleague of mine is also working on replacing the EJB
backend with a Web services implementation, so this should be a nice
and round, example of the possibilities of Cocoon.
Another line of action would be to investigate how this stuff and the
TreeProcessor will fit together. My Scheme stuff is likely to not
support some of the old stuff from the compiled sitemap, which
Sylvain's TreeProcessor implementation supports. The easiest way right
now is to have different subsitemaps running using different
implementations. I haven't done any tests yet, but it should be
possible to have a TreeProcessor sitemap implementation mount a Scheme
sitemap implementation. This is suboptimal though, as one will not be
able to take advantage of the old features together with the new ones,
unless things are separated in different sitemaps. A better thing to
do is to hookup the mechanism for calling Scheme functions in the
TreeProcessor implementation directly, in which case the Scheme
sitemap implementation becomes useless. We'll see as things evolve
what's the best way to proceed.
Regards,
--
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: first impressions on continuations idea
Posted by Judson Lester <ju...@irev2.com>.
Hey there Ovidiu. I don't know if Allan reads the dev list, but regards if
he's listening.
> > But I've made my way through the papers you sent, and the relevant
> > threads - I really love it.
>
> I loved it too when I saw it the first time ;-)
>
Which makes at least three of us. Too often the navigational flow of a site
is lost because it's entirely encoded at the document level, or in an
instance by instance level. It would be so much better to be able to
describe it all in one place.
> > Would a session not be the appropriate place to store continuations and
> > associated data? The URL strikes me as a really bad idea, as it should
> > be a logic-level address (ie foo.com/add) rather than an implementation
> > level (foo.com/add/4ff.) Under what circumstances might you wish not to
> > resort to session?
>
> This is a good question.
>
> If you look at the concept of session in the servlet environment, you
> realize it's only a way to save state across HTTP requests. But with
> continuations, you no longer need this! The continuation saves in it
> the complete stack frame of calls, including local variables. When a
> continuation is resurrected, it will contain the values for all the
> local variables you declare.
>
> What you're referring to is probably not session, but cookies. The
> problem is you cannot use cookies to encode the continuation's URL, as
> this would prevent the user from hitting the back button. This happens
> because the cookie is set globally, for the whole domain. Hitting the
> back button will not change the cookie's value to point to the right
> page.
>
> So clearly you need a way to encode the continuation's URL in the page
> itself, rather than assign it to a cookie.
>
I personally agree with Allan, that trying to encode a user in his URL is
problematic. However, I don't see why it would be impossible to establish a
cookie backed session, and then store the coninuation tree in the session,
with a map of URLs to continuations. This gives you the session-hijacking
protection established by Servlet session scopes, but allows you to also get
back-button-to-previous-continuation feature that Ovidiu has slowly brought
me to understand completely.
> The last step is to write a translator from a more friendly language
> to Scheme. This is the hardest part, as I'm not sure what features
> this language needs to have. I'm trying to decide on this, and
> prototype a little bit with it.
>
Did you want to discuss at all your thinking in this regard?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: first impressions on continuations idea
Posted by Allan Erskine <a....@cs.ucl.ac.uk>.
> What you're referring to is probably not session, but cookies. The
> problem is you cannot use cookies to encode the continuation's URL, as
> If you look at the concept of session in the servlet environment, you
> realize it's only a way to save state across HTTP requests. But with
> The
> problem is you cannot use cookies to encode the continuation's URL, as
> this would prevent the user from hitting the back button. This happens
> because the cookie is set globally, for the whole domain. Hitting the
> back button will not change the cookie's value to point to the right
> page.
> So clearly you need a way to encode the continuation's URL in the page
> itself, rather than assign it to a cookie.
Hmm - I think there are two separate issues here. First, the back
button/multiple browser problem. I think I remember Stefano referring
to the "evil" back button, and even though Queinnec's papers tried to
address it, I don't think it's necessary to force schecoon to use
continuations in the same way. There are other ways to deal with the
problem, e.g. disabling the offending causes.
But if you did want to deal with the back/multi-browser problem with
continuations, you wouldn't need a continuation URL stored in the page.
Just some unique continuation ID (a hidden field say). All exits from a
page would send this ID in the request for a new page. Before running
the continuation you clone it (you can do this right?) in case another
page tries to run the same continuation in a different direction.
URL request parameters could even be used, e.g. foo.com/next?cont-id=4ff
as one choice foo.com/finish?cont-id=4ff as the other. I just don't
think hard-coded continuation URLs are a nice idea.
So continuations aren't really being used in a similar way to session ID
here (was this your point?)... using the same cont-id can branch the
program in a different direction by sending a different request for that
continuation, with the choice of next action logically named in the
URL/some-other-request-param. There's only ever one continuation of a
running program anyway (the current one). But this continuation can be
branched in different directions, depending what's asked for.
Whoops, Ovidiu's just landed on the list, so I'll carry on after...
Allan
-----Original Message-----
From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com] On Behalf
Of Ovidiu Predescu
Sent: 01 February 2002 02:51
To: Allan Erskine
Cc: cocoon-dev@xml.apache.org
Subject: Re: first impressions on continuations idea
Hi Allan,
[I've Cc-ed cocoon-dev, as I believe you bring up some good points.]
On Fri, 1 Feb 2002 00:32:50 -0000, Allan Erskine
<a....@cs.ucl.ac.uk> wrote:
> Sorry this has been long in coming - it's really busy for me right
now.
No problem, it's been busy for me too.
> But I've made my way through the papers you sent, and the relevant
> threads - I really love it.
I loved it too when I saw it the first time ;-)
> For a start it plain old smacks of a good idea - anyone who's suffered
> the indignity of having to code a web-app must surely weep at the
> concise flow programs in Queinnec's papers.
I definitely agree with you.
> Secondly I love the idea that we can start to use higher-order
language
> features throughout the web-app development process. Instead of
> HTML/XML/validation code/backend code/actions which is just
> unmanageable.
Yes, it's just a pain to do this, and Cocoon and all the other
frameworks really suck in this respect.
> So I'd be really interested in what you plan to do with this schecoon
> web-app example.
>
> Starting with the example code you put up on cocoon-dev:
>
> Ovidiu said:
> >
> > Because of the continuations, the URLs for the second and third
pages
> > would probably look more like:
> >
> > http://foo.com/add/4ffds8454mfd90
>
> Would a session not be the appropriate place to store continuations
and
> associated data? The URL strikes me as a really bad idea, as it
should
> be a logic-level address (ie foo.com/add) rather than an
implementation
> level (foo.com/add/4ff.) Under what circumstances might you wish not
to
> resort to session?
This is a good question.
If you look at the concept of session in the servlet environment, you
realize it's only a way to save state across HTTP requests. But with
continuations, you no longer need this! The continuation saves in it
the complete stack frame of calls, including local variables. When a
continuation is resurrected, it will contain the values for all the
local variables you declare.
What you're referring to is probably not session, but cookies. The
problem is you cannot use cookies to encode the continuation's URL, as
this would prevent the user from hitting the back button. This happens
because the cookie is set globally, for the whole domain. Hitting the
back button will not change the cookie's value to point to the right
page.
So clearly you need a way to encode the continuation's URL in the page
itself, rather than assign it to a cookie.
Now if you do this, on the server side you need a way to extract the
continuation's id from the request, obtain the continuation and invoke
it. Rather than imposing a fixed URL scheme, I now believe the task of
identifying the continuation's id should be left to the sitemap. A
sitemap admin could map continuations to different URLs, to fit the
general look of the URL on that site. Something like this:
<map:match pattern="continue/(.*)">
<map:call function=invoke-continuation">
<map:parameter name="id" value="{1}"/>
</map:call>
</map:match>
"invoke-continuation" is a special function which takes a continuation
id, determines the continuation, and invokes it, effectively
restarting the processing.
> Ovidiu said:
>
> > You can then mount each function at different URLs:
> >
> > http://foo.com/first/
>
> Just checking - you'd intend this to be mapped automatically from the
> function name?
No, it's also based on the sitemap. Check-out the current sitemap in
schecoon, to see how this is done:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/schecoon/we
bapp/sitemap.xmap?rev=1.2&content-type=text/vnd.viewcvs-markup
> Ovidiu said:
>
> > send-page("show-shopping-cart.xml");
> > operation = request.getParameter("operation");
> > if (operation == "continue-shopping")
> > send-page("continue-shopping");
> > else if (operation == "buy")
> > buy();
> > else if (operation == "update-quantities")
> > update-quantities();
>
> I realise this was just a first attempt to demonstrate a Javascript
like
> language, but the sort of code above is going to appear _all_ the
time.
> And it is loosely cohesive too, since presumably in
> show-shopping-cart.xml there are magically-named fields corresponding
to
> the operations "continue-shopping".
>
> Surely it would be much nicer to have each page defined as a
first-class
> entity + operations _within_ your flow-language. Encourage the OO
> style, e.g. this sort of thing
>
> Class customer {
> IDType ID;
> String name;
> String address;
> }
>
> class Cart {
> customer c;
> order_goods gs;
> }
>
> //class page is predefined, included reflecting show method
>
> class Cart_page : page {
> Cart c;
> buy() { new Checkout_page(c).show() }
> continue_shopping() { new Shopping_page(c).show() }
> .
> }
>
> With the continuation handling stuff in the predefined show() methods.
> All the xml would be generated automagically. Code-generators could
> also be written for various backend solutions. There are plenty of
> object-models available out there for scheme. All you'd have to write
> would be the transforming code.
I'm sure this would be an option for us, programmers, but Web page
designers would probably still want their HTML/XML pages.
I believe the send-page(xml-filename, pipeline-name, data-dictionary)
makes for a more separation between flow, logic and presentation.
> Ovidiu said:
>
> > Also I don't like to express logic in XML, it's not what it was
> > designed for. We need a programming language, so why use an XML
syntax
> > to express this? The attempts to use XML to implement a programming
> > language are taking XML too far, where it wasn't designed to work.
> >
> > --
> >
> > I think with the new model, there's no need for actions, redirects
and
> > other things that the sitemap currently has. They are no longer
needed
> > as you have full control over what's going on in your application at
> > the program level. And you can control your application in a much
> > better way than before.
> >
> > In the new model, the sitemap becomes a dispatcher to either a
> > pipeline, or to a function in our language with implicit
continuations
> > (any good name for it?).
>
> All this is what I like best. It will let C2 return to what it's good
> at. The poor old sitemap is groaning under the stress. And actions
are
> *@#$!
Yep!
> So what would be the first step? A flow-program generator for the
> schecoon sitemap?
Right now I have a simple XML sitemap implementation written entirely
in Scheme. It allows me to specify:
- matchers that contain simple pipelines, that contain either of
these:
- generator transformer* serializer
- reader
- call resource
- call a Scheme function
- resources: these are simple pipeline definitions, which have a name
associated with them.
The Scheme implementation reads an XML sitemap and translates it into
Scheme code. The resources are translated to Scheme functions, so
calling a resource is nothing else than calling a Scheme function
(read very fast, possibly faster than today's compiled sitemap
approach, though I didn't test it yet).
You can declare Scheme functions to be called from the sitemap. These
functions are defined in a special way, which allows the sitemap to
pass named arguments, without having to be worried about their
position as formal arguments of the Scheme function.
The next step is to implement the mechanism for storing continuations,
identifying them, and invoking them on request. This should be easy to
do. Once this last step is done, you can start writing flow programs
in Scheme!
The last step is to write a translator from a more friendly language
to Scheme. This is the hardest part, as I'm not sure what features
this language needs to have. I'm trying to decide on this, and
prototype a little bit with it.
As a showcase for the new Cocoon architecture, I'm thinking to take
the J2EE PetStore application and rewrite it with Cocoon's flow
support. A colleague of mine is also working on replacing the EJB
backend with a Web services implementation, so this should be a nice
and round, example of the possibilities of Cocoon.
Another line of action would be to investigate how this stuff and the
TreeProcessor will fit together. My Scheme stuff is likely to not
support some of the old stuff from the compiled sitemap, which
Sylvain's TreeProcessor implementation supports. The easiest way right
now is to have different subsitemaps running using different
implementations. I haven't done any tests yet, but it should be
possible to have a TreeProcessor sitemap implementation mount a Scheme
sitemap implementation. This is suboptimal though, as one will not be
able to take advantage of the old features together with the new ones,
unless things are separated in different sitemaps. A better thing to
do is to hookup the mechanism for calling Scheme functions in the
TreeProcessor implementation directly, in which case the Scheme
sitemap implementation becomes useless. We'll see as things evolve
what's the best way to proceed.
Regards,
--
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org