Chris
Reinhard Pötz wrote:
This mail should prepare the upcoming vote on the Cocoon flow implementation.
Some points are pretty clear but some would need some more comments - especially
- stateful components -> how to release them? - continuation object
- o -
Here are the points we should vote on:
************************************************************** * FOM (Flow Object model) * **************************************************************
Stefano:
The vote clearly indicates the community wants the "small -> big" approach. Chris has also removed his concerns. This gives us green light to go ahead and finish the FOM design as we proposed it.
Fine. Here you find the updated "small version" of the FOM: http://wiki.cocoondev.org/Wiki.jsp?page=FOM
The update contains following changes since the initial draft has been published:
Context object
--------------
--parameters--
getInitParameter(name)
If I interpret this correctly you would provide the web.xml parameters as properties. Another possibility would be the attributes. Stefano, what do you think?
Anyway, I updated the FOM draft at the Cocoon Wiki! containing both alternatives.
This will be no extra point for the vote but will be part of the FOM.
Session object --------------
Vadim suggested that we make the session object available as a property of the cocoon object instead thru the getSession() method and I agree that this might be desirable and provide consistency.
Added to the FOM draft.
Cookie object ------------- Added name and version property (as suggested by Vadim).
This could be the base for the vote. So please have a look at it!
Environment object ------------------ Question on the environment: Currently the sendPage functions are implemented using Cocoon.environment:
this.cocoon.forwardTo("cocoon://" + this.cocoon.environment.getURIPrefix() + uri, bizData, wk);
How can we implement this without the environment object?
Additinally the method cocoon.forwardTo( uri, bizData, wk) is not available too!
Notes to the vote: ++++++++++++++++++ The link http://wiki.cocoondev.org/Wiki.jsp?page=FOM contains the current status of discussion. We can vote on the complete draft!
The points
- Script load support - Modules (input/output)
- Continuations Object - callAction(..)
are excluded because we should vote on them separatly.
************************************************************** * Component loading * **************************************************************
I see two different types of components in Cocoon today:
1) general components (example: SaxParser) 2) sitemap components (example: FOPSerializer)
I think the flow should have access only to the first family.
<snip/>
So, for today, the FOM should be implemented that only general components are loadable and they are identified thru their roles or their short names (as listed in the role file)
I'm not a ECM specialist. Does anybody have an idea how to solve this? Maybe the "FOM component manager" does a lookup into the roles and can decide wheter it is a general component or not ...
Note on the vote:
+++++++++++++++++
So the question at the vote could be:
"Should the flow have only access to general components and can't access any sitemap components?"
************************************************************** * statefull components - how to release them? * **************************************************************
Stefano/Ricardo:
Ricardo and I discussed this extensively a night ago. My proposalwould
be to add a call such ashave
sendPageAndFinish()
that would remove all the continuations from the tree and free all loaded components.
but there are still a bunch of issues with the use of stateful
components in a continuation-driven environment and I'm not sure we
enough information just yet to understand what is the best way tohandle
this.and
So, it would be best to let the flow writer take care of everything
inprovide a dispose() hook to the FOM, potentially deprecatable once we idenfity how to do transparent component garbage collection in a continuation-driven environment and stateful components that are not aware of this.
Still, the mix between continuations-based state handling and other
forms of state handling (say, transparent EJB transactionality, for
example) will very likely become the single focus of future research
this community.
Sylvain:
I think there are only two reliable ways to manage statefulcomponents:
1/ raise an error if there are some unreleased stateful componentswhen
a continuation is created.be
2/ tie releasing of a component to the death of the continuation to which it belongs.
Solution 1/ solves the problem by suppressing its cause. Although it seems very strict, we can also consider that application state should
kept by script variables and and not state of components. This is similar to your remark about EJB statefull session beans : keep statein
the webapp an not in the container.
Solution 2/ can answer transparently to your "function" policy. If the
whole continuation tree is invalidated at function completion on oneof
the branches, all components looked up since the function started are automatically released.open
Although solution 2 seems nice, I still find it dangerous to allow heavyweight resources to float around between requests. This is an
door to many memory and performance problems if this feature isabused.
Also, it strongly prevents session serialization and thus the use of flowscript on failsafe servers. So I would go for solution 1, which enforces careful state management.
Note to the vote: +++++++++++++++++ Currently I don't know what we should vote on. Maybe someone with more in depth knowledge could summarize the possible options!
************************************************************** * Flow and sessions * **************************************************************
Current implementation:
1. The global scope of a flow only lives as long as the session which the flow is tied to is active.
So if the session expires or you use another client to continue a 'waiting' function you only have access to the local scope within the flow function.
2. All scripts within a <map:script>...></> part share the same global context. If you want to share more objects you need another scope (request, session, context).
Stefano:
I haven't written a flowscript that didn't require, in some way or another, the availability of some statefulness on data and it seems to me as overkill to use full execution state preserving (and the URI-encoding of the continuation every time!) just for the data (besides, even today, if you want to keep global flow variables around, you have to enable sessions anyway)
In general, it is true that continuations and sessions are different beasts, but in real life, continuations *extend* sessions since they provide the ability to save *even more* state than sessions.
But in those situations where procedular flow is weak and navigation decisions are driven by user action and not by flow execution, continuations are overkill and sessions are still the preferred way to go.
is there a real need for continuations without sessions? i really can't provide a meaningful example of this.
so, I would say +1 to this.
Sylvain (answering on Pier's "registration centre" use case):
A continuation tree is actually the "flow instance" you're talking about. So you can have different flow instances running concurrently smoothly, provided that their state is only stored in local variables.
Global variables should be used to represent state that is user-dependent but not flow-dependent.
Note to the vote:
+++++++++++++++++
So I think we could vote on the current implementation or can anybody come up with a use case that is not covered with the current implementation?
************************************************************** * Map callAction(name,map) * **************************************************************
Note to the vote: +++++++++++++++++ Okay, this will be a simple yes/no question.
************************************************************** * Continuations Object * **************************************************************
Uh, you're right. I overlooked that.
I really have mixed feelings about this. Currently, the WebContinuation object is exposed to the FOM and used in system.js to implement sendPageAndWait(). I don't like this because it exposes too much of the continuation machinery internals to the flow layer.
So, at least, if the continuation object is left, the ability to contruct a new continuation should not be exposed in the FOM.
But at the same time, why would we need direct access to the continuation object? the only valid reason is to invalidate the continuation, but again, it feels kinda anti-scripting to have to go chasing the continuation and invalidate it.
does anybody have a real-life example of the need for having access to the continuation object?
Sylvain (http://marc.theaimsgroup.com/?l=xml-cocoon-dev &m=105472379523896&w=2)
Again, the notion of "use-case completion" is intimately tied to the various branches that exist on the continuation tree. Some use cases, such as a shopping cart, will want to ensure that no other branchstill
exists when the end of the function is reached (i.e. the order is placed). To achieve this, the solution is to create a continuation at the start of the function, and invalidate it when one of the branches reaches the end of the function. The whole continuation tree is then invalidated.
Reinhard:
I think we need the continuations object available within the flows. Especially if you write "high advanced" flows (look at the JXForms implementation) you need access to the continuations object since you have to create continuations without sending a page. Without this "trick" the next-previous navigations wouldn't work.
What do you think?
Note to the vote: +++++++++++++++++ This is a simple yes/no question too.
************************************************************** * Modules (input/output) * **************************************************************
Stefano:
what modules?
I meant the input and output modules. I think there is information available in input modules (e.g. static global parameters) that could be useful within flows.
Output modules could be useful too. But maybe Christian could come up with more detailed explanations.
Note to the vote: +++++++++++++++++ This is a simple yes/no question too.
************************************************************** * Script load support * **************************************************************
Stefano/Ricardo:
The reason for removing load() is because we want to avoid people from loading scripting dynamically. This goes in parallel with the anti-pattern of dynamic pipeline construction.
WARNING: removing load() does *NOT* imply that you have to force all your flow in one big file. The way to fragment your flow into different files is to use several <map:script> elements in the <map:flow> section of the sitemap.
Sylvain:
Load support is IMO required because JS lacks an import statement. Not
having it means we'll have to write a <map:script> for the script we want to use, but also for *all the scripts it depends on*,recursively.
This will be very difficult to manage.
Stefano:
since we agreed that blocks only expose a URI space controlled by theto
sitemap (they don't expose resources directly!) you can use a reader
doneget the flow to the dependent block, or you can use a pipeline to generate your flow (for example, traducing a workflow written using a markup language into the equivalent flow instructions).
Here you have all the machinery you need to compose your flows as you like. Recursively.
The difference between the above and load() is thin but real: while
load() has to be executed at runtime, the <map:script> calls can be
at sitemap assembly time. It could have a big impact on runtime
performance of the flowscripts.
Note to the vote: +++++++++++++++++ Simple question: Do we support the load() function within scripts?
- o -
Are there any other open points! Please speak now!
Reinhard
