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 proposal
would
> be to add a call such as
>
> 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
have
> enough information just yet to understand what is the best way to
handle
> this.
>
> So, it would be best to let the flow writer take care of everything
and
> provide 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
in
> this community.
Sylvain:
> I think there are only two reliable ways to manage stateful
components:
> 1/ raise an error if there are some unreleased stateful components
when
> a continuation is created.
> 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
be
> kept by script variables and and not state of components. This is
> similar to your remark about EJB statefull session beans : keep state
in
> 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 one
of
> the branches, all components looked up since the function started are
> automatically released.
>
> Although solution 2 seems nice, I still find it dangerous to allow
> heavyweight resources to float around between requests. This is an
open
> door to many memory and performance problems if this feature is
abused.
> 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 branch
still
> 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 the
> sitemap (they don't expose resources directly!) you can use a reader
to
> get 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
done
> 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
