Page: http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow , version: 6 on Wed Jun 25 15:56:51 2003 by ReinhardPoetz
- Here you find a summary of open design, implementation and documentation issues of the Cocoon control flow. I know we have Bugzilla but I think it is easier to follow the open issues and the discussion as a whole if we use Wiki!. + Here you find a summary of open design, implementation and documentation issues of the Cocoon control flow. I added some comments in order to give an overview of the current discussion. If somebody feels that I haven't citied correctly feel free to correct me! + + I know we have Bugzilla but I think it is easier to follow the open issues and the discussion as a whole if we use Wiki!. + ---- + - __cocoon.environment.getURIPrefix()__ ? ^^ -- + !cocoon.environment.getURIPrefix() ? ^ - __continuations__ ? ^^ -- + !continuations ? ^ - __modules support__ ? ^^ -- + !modules support ? ^ - __script load support__ ? ^^ -- + !script load support ? ^ - __callAction__ ? ^^ -- + !callAction ? ^ - __allow actions to wrap call function elements in sitemap__ ? ^^ -- + !allow actions to wrap call function elements in sitemap ? ^ - + ---- - __Component loading__\\ ? ^^ ---- + !Component loading ? ^ + + (SM) ''I see two different types of components in Cocoon today: + #general components (example: SaxParser) + #sitemap components (example: FOPSerializer) + I think the flow should have access only to the first family.'' + + + !Release of statefull components + + (SW) ''Ithink there are only two reliable ways to manage stateful components:\\ + #__raise an error__ if there are some unreleased stateful components when + a continuation is created.\\ + #__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.'' + + + (SM/RR) ... ''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.'' see [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105588661921571&w=2] + + !Event handling + function handlingcocoon.addEventListener(); function cocoon.removeEventListener() - __Release of statefull components__ - *... - *... - __Event handling__\\ - function handlingcocoon.addEventListener(); function cocoon.removeEventListener() - *... - *... - - __ClassCastExceptions (FOM_Request != Request)__ ? ^^ -- + !ClassCastExceptions (FOM_Request != Request) ? ^ - __Calling internal only pipelines__\\ ? ^^ ---- + !Calling internal only pipelines ? ^ - __Continuations expiration__ ? ^^ -- + !Continuations expiration ? ^ - __Passing input module parameters to the flow__ ? ^^ -- + !Passing input module parameters to the flow ? ^ - __Syncing Rhino__ ? ^^ -- + !Syncing Rhino ? ^ + ---- + ---- - __move JXTemplateGenerator from scratchpad to main trunk__ ? ^^ -- + !move JXTemplateGenerator from scratchpad to main trunk ? ^ - __move JXForms from scratchpad to main trunk__ ? ^^ -- + !move JXForms from scratchpad to main trunk ? ^ - __move Petstore from scratchpad to main trunk__ ? ^^ -- + !move Petstore from scratchpad to main trunk ? ^
