cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: first impressions on continuations idea
Date Fri, 01 Feb 2002 02:51:02 GMT
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 <> 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:
> >  
> >
> 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 rather than an implementation
> level (  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

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}"/>

"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:
> >  
> >
> 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:

> 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
> *@#$!


> 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

  - 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.

Ovidiu Predescu <> (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message