cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [RT] Flowmaps
Date Wed, 19 Jun 2002 22:52:19 GMT
On 6/18/02 7:59 AM, "Sylvain Wallez" <>

> Ovidiu Predescu wrote:
>> Guys,
>> I'm really overwhelmed by your reaction to the flow idea! Thanks all for
>> sharing your thoughts!
>> First of all, I think the thanks should go to Christian Queinnec, who came
>> up with the idea, and to Christopher Oliver, who implemented continuations
>> in Rhino. I just put all the things together and implement the support in
>> Cocoon.
> A question about Christopher Oliver : is he using Cocoon, or is he using
> the continuation-enabled version of Rhino in another context ?

I think he's using the modified Rhino in another context.

>> 1. Stefano points out that flowmaps (I don't really like this term, a "map"
>> is more appropriate for state machines, how about flowscript instead?)
>> should not be considered as ordinary resources, but a separate concept. I
>> have no issue declaring them in a different way, just to emphasize this
>> point. So something like
>>  <map:flowscripts default="calculator">
>>   <map:flowscript name="calculator" language="javascript">
>>     <map:script src="calc.js"/>
>>   </map:flowscript>
>>  </map:flowscripts>
>> should be OK. Beside a different name for elements, the fundamental
>> difference between this syntax and Stefano's is that it allows multiple
>> files to contain the implementation of a flow script.
> I think we are too much focused on either "script" or "map" : the flow
> engine is a controller (in the MVC sense), and it doesn't really matter
> whether it is defined by a script or a map. We currently have one
> implementation which is JavaScript, but some people seem to prefer state
> automata, and it is certainly possible to write an implementation based
> on an XML file describing a state automaton. Note also that Ovidiu also
> likes Scheme, so this makes a third candidate implementation ;)
> So what about a simple <map:flows> composed of named <map:flow>, or even
> a <map:controllers> composed of <map:controller> ?

I would agree with you here. <map:flows> as the container and <map:flow> for
a particular flow, seem like better names.

> Also, the <map:script> element is intimately tied to the fact that the
> enclosing <map:flowscript> is of the JavaScript language, and this
> strongly looks like a component configuration. So once again, is there a
> fundamental difference between actions, matchers, etc, and flows ?
> I really don't think so, and consider a flow to be a new kind of sitemap
> component with the associated primitives in the sitemap language. This
> feeling is also encouraged by the fact that we all agree that there
> should be no symmetry between the sitemap and flow, and that the sitemap
> is the main entry point that drives everything else.
> So we could have :
> <map:components>
> <map:generators>
>   ...
> </map:generators>
> ...
> <map:flows>
>   <map:flow name="calculator"
> src="org.apache.cocoon.components.flow.JavaScriptInterpreter">
>     <!-- specific configuration for JavaScriptInterpreter -->
>     <script src="calc.js"/>
>   </map:flow>
> </map:flows>
> </map:components>
> <map:pipelines>
> ...
> Thoughts ?

Your assumption is that the flow scripts are visible to all the
applications. I don't think this is reasonable. Just think of an ISP who
deploys Cocoon, people running their Web app want to be isolated from
everybody else. How can we achieve this if we describe flow scripts as
components, inheritable in all the Cocoon blocks that implement user apps?

>> Each named flow script declared in <map:flowscripts> could and should be
>> independent on the others. Each script should have different set of global
>> variables, which is different from another script, and of course, is
>> different each user gets his/her own set of values for these variables.
> This IMO enforces the fact that they are individual component instances.

But it doesn't prevent other flow scripts deployed in the same Cocoon
instance to reverse engineer scripts deployed by somebody else (think of the
ISP scenario).

>> 2. (Stefano) How to encode the continuation ids.
>> Stefano would like to have ContinuationURLEncodingTransformer, which takes
>> care of encoding the continuation id. Sylvain points out that continuation
>> ids can be passed not only as part of the URL, but also as request
>> parameter.
>> I think it makes sense to have a transformer which encodes the continuation
>> URL. This would make it very easy to change the way the continuation id is
>> generated, without having to go to each XSP, JSP, whatever and change it.
>> The transformer would probably work best when the continuation id is encoded
>> in the URL. When the id is encoded as a request parameter, there will be
>> some awareness required from the page designer to have this id enclosed
>> inside a form.
> It will be good to provide a default mechanism that will make it as
> transparent as possible, but we must keep the door opened for specific
> needs (I'm mainly thinking of ids contained in a SOAP message).

Yes, me too. Some current SOAP-based protocols make use of ids encoded
inside messages.

>> 5. Ivelin points out the potential of stale continuations.
>> I think this is indeed a real issue. One way to avoid it is to have
>> continuations automatically expire after a time of inactivity, or do
>> deactivate them manually in the flow script. The first approach is something
>> I considered, and there are some hooks in the current code, but more support
>> code needs to be written. The second approach can be implemented today: you
>> can invalidate not only a single continuation, but the whole subtree of
>> continuations which start from it. You just need to keep a hold on the
>> continuation at the top of the tree, and invoke invalidate() on it.
> We could also swap some old but not expired continuations on disk.

Yes, indeed, this should be possible. Christopher Oliver added support for
this type of scenarios as well in his Rhino version.

>> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>> If you think of using Cocoon for building Web apps or Web services, and you
>> need support in doing so, I am providing consultancy for doing it, anytime,
>> anywhere.
> Hey, what about posting this to cocoon-users, which certainly has a
> greater potential of people searching for consultancy than cocoon-dev.
> As Stefano says, "this is how the community pays back", and you deserve it.

Good idea, I'll do it!


Ovidiu Predescu <> (Apache, GNU, Emacs...)

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

View raw message