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 ?
>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> ?
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 ?
>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.
>This is an issue today, as it does not really happen. I'm working on solving
>it.
>
>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).
<snip/>
>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.
<snip/>
>13. Piroumian asks how to cancel a continuation.
>
His first name is "Konstantin" ;)
<snip/>
>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.
>Thanks for reading so far,
>Ovidiu
>
>
Thanks for this great work,
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
