cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [Flow] Preparing the vote - long!
Date Thu, 19 Jun 2003 16:10:16 GMT
Reinhard, thank you very much for this great summary of the FOM issues 
(and for the Wiki)!

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



Mime
View raw message