You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2003/10/06 15:00:07 UTC
[WIKI-UPDATE] GT2003HackathonFlow +GT2003FlowHandling GT2003HackathonJsr170 GT2003Hackathon Mon Oct 6 15:00:07 2003
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonFlow , version: 1 on Mon Oct 6 12:05:21 2003 by BertrandDelacretaz
New page created:
+ Raw notes taken collaboratively during the talk.
+
+ !!! Carsten on Flow
+
+ ! Breaking up Flowscripts in smaller pieces
+
+ Explains how Flow basically works. His view of Flow is that you write a big javascript file for your application, which is not good.
+
+ Carsten would like to split the big javascript into several parts, smaller pieces ("flow units") of javascript which do their work and pass control to the next "Flow unit". Wouldn't need a different implementation of Flow, only a different way of doing things.
+
+ ! Aggregating several Flow applications in a single page
+ Is is possible to handle several Flow applications in coplets on a portal page?
+
+ According to Sylvain this is possible, each coplet can have its own continuation. The only problem currently is that continuations which are not used might expire. Making a distinction between "refresh" (used to refresh pages only) and "active" continuations might help.
+
+ !!! Marc on continuations and Apples
+
+ Starts by saying that he's not going to talk about Apples (Yoko Ono wouldn't like it anyway ;-)
+ Who did believe him?
+
+ ! Possible race conditions in continuations cleanup?
+
+ Currently in Cocoon there is the "web continuation" distinct from the "native continuation".
+
+ The native continuation holds all the stack information, where you're at in the currently executing script. Technically it is like an opaque container, handled by the ContinuationManager.
+
+ Every sendPageAndWait creates a new continuation - the forest of continuations is managed by the ContinuationManager. Destroying continuations is different from invalidating them.
+
+ ToDo: are there race conditions in continuation management? He's worried about complexity in the removal/cleanup of expired continuations. Today all continuations are handled in the scope of one session/one user, so potential problems might not have been exposed yet.
+
+ Marc would like to create a test case today, for possible race conditions.
+
+ !! Apples
+
+ ! Subtrees of continuation stored in Java objects
+ He's been experimenting with "subtrees" of continuations, where a subtree stores all intermediate states of your "use case". Stefano asks what exactly a "use case" is in this context. Storing a tree of continuations into a java object would allow REST-like access to every step of the use case (are we still following this? (I am getting lost here) ;-) (it's about whether you want magic managing your application state, or you would like to know what is really going on ;-)
+
+ Marc thinks that, based on his analysis, some name changes in the continuations stuff might be of order.
+
+ Using URLs to access continuations which represent steps in a use-case (form-filling for example) could make it easier to:
+ * Fill several forms at the same time, for example when filling a form and getting a phone call which makes you start filling another instance of the same form.
+
+ * Sharing form filling between multiple users simultaneously (help line, etc) this is possible because that 'form' (actually every step of it IIUC) has it's own dynamic URL
+
+ Someone asks: Why?
+ We'll let Marc fill you up on this one later ;-)
+
+ ! Continuations management
+ According to Marc the only thing missing is the ability to gracefully end continuations: letting the user work on it if currently active, but do not allow the starting of new use cases.
+
+ Example: big deployment, need to let users finish their work before stopping a system.
+
+ In this state, new continuations could be created for "call continuation" but not for "call function" to prevent the starting of new use cases.
+
+ Should this be handled at the application of system level? It could be simple enough at the application level.
+
+ ! Concurrency
+ Today it is not possible to have two users work on the same continuation simultaneously.
+
+ The question seems to be more about sharing application data state than sharing continuations per se. We need to find a balance between making it easy yet not breaking concepts like continuations and sessions, which are not meant to be shared.
+
+ Flow Interpreter Interface:
+
+ {{{
+ callFunction (func, args, environment)
+ handleContinuation (id, args, environment)
+ }}}
+
+ These are all you need to implement to write your own Flow Engine.
+
+ !!! Reinhard on interceptions in Flowscript
+
+ ! Scratchpad prototype
+
+ AOP/interceptions in Flowscript
+
+ Reinhard has written a prototype in the Cocoon scratchpad offering five interception points:
+
+ !Event-driven approach
+ Has been implemented by Reinhard using an Observer pattern: his code registers with the interpreter to observe function calls.
+
+ * before
+ * after
+ * around (replaces a function by another)
+ * stop execution
+ * continue execution
+
+ Is static interception enough?
+
+ ! Use-cases
+ Reinhard sees the possibility of customizing apps without modifying them.
+
+ Authentication could be another use.
+
+ !Wrapping Approach
+ Decorator Pattern - actually intercept function calls by delegating them to the original code after "pre-processing".
+
+ Stefano: Wrap a flowscript?
+ * Call my starting code
+ ** Excecute the wrapped FlowScript
+ * Call my ending code
+
+ Decorator vs. Observer pattern discussion.
+
+
+
+
+
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=+GT2003FlowHandling , version: 3 on Mon Oct 6 12:06:48 2003 by BertrandDelacretaz
- Raw notes taken collaboratively during the talk.
+ Sorry there are two pages with this names, one with a space in front causing problems. See [GT2003HackathonFlow] instead.
- !!! Carsten on Flow
-
- ! Breaking up Flowscripts in smaller pieces
-
- Explains how Flow basically works. His view of Flow is that you write a big javascript file for your application, which is not good.
-
- Carsten would like to split the big javascript into several parts, smaller pieces ("flow units") of javascript which do their work and pass control to the next "Flow unit". Wouldn't need a different implementation of Flow, only a different way of doing things.
-
- ! Aggregating several Flow applications in a single page
- Is is possible to handle several Flow applications in coplets on a portal page?
-
- According to Sylvain this is possible, each coplet can have its own continuation. The only problem currently is that continuations which are not used might expire. Making a distinction between "refresh" (used to refresh pages only) and "active" continuations might help.
-
- !!! Marc on continuations and Apples
-
- Starts by saying that he's not going to talk about Apples (Yoko Ono wouldn't like it anyway ;-)
- Who did believe him?
-
- ! Possible race conditions in continuations cleanup?
-
- Currently in Cocoon there is the "web continuation" distinct from the "native continuation".
-
- The native continuation holds all the stack information, where you're at in the currently executing script. Technically it is like an opaque container, handled by the ContinuationManager.
-
- Every sendPageAndWait creates a new continuation - the forest of continuations is managed by the ContinuationManager. Destroying continuations is different from invalidating them.
-
- ToDo: are there race conditions in continuation management? He's worried about complexity in the removal/cleanup of expired continuations. Today all continuations are handled in the scope of one session/one user, so potential problems might not have been exposed yet.
-
- Marc would like to create a test case today, for possible race conditions.
-
- !! Apples
-
- ! Subtrees of continuation stored in Java objects
- He's been experimenting with "subtrees" of continuations, where a subtree stores all intermediate states of your "use case". Stefano asks what exactly a "use case" is in this context. Storing a tree of continuations into a java object would allow REST-like access to every step of the use case (are we still following this? (I am getting lost here) ;-) (it's about whether you want magic managing your application state, or you would like to know what is really going on ;-)
-
- Marc thinks that, based on his analysis, some name changes in the continuations stuff might be of order.
-
- Using URLs to access continuations which represent steps in a use-case (form-filling for example) could make it easier to:
- * Fill several forms at the same time, for example when filling a form and getting a phone call which makes you start filling another instance of the same form.
-
- * Sharing form filling between multiple users simultaneously (help line, etc) this is possible because that 'form' (actually every step of it IIUC) has it's own dynamic URL
-
- Someone asks: Why?
- We'll let Marc fill you up on this one later ;-)
-
- ! Continuations management
- According to Marc the only thing missing is the ability to gracefully end continuations: letting the user work on it if currently active, but do not allow the starting of new use cases.
-
- Example: big deployment, need to let users finish their work before stopping a system.
-
- In this state, new continuations could be created for "call continuation" but not for "call function" to prevent the starting of new use cases.
-
- Should this be handled at the application of system level? It could be simple enough at the application level.
-
- ! Concurrency
- Today it is not possible to have two users work on the same continuation simultaneously.
-
- The question seems to be more about sharing application data state than sharing continuations per se. We need to find a balance between making it easy yet not breaking concepts like continuations and sessions, which are not meant to be shared.
-
- Flow Interpreter Interface:
-
- {{{
- callFunction (func, args, environment)
- handleContinuation (id, args, environment)
- }}}
-
- These are all you need to implement to write your own Flow Engine.
-
- !!! Reinhard on interceptions in Flowscript
-
- ! Scratchpad prototype
-
- AOP/interceptions in Flowscript
-
- Reinhard has written a prototype in the Cocoon scratchpad offering five interception points:
-
- !Event-driven approach
- Has been implemented by Reinhard using an Observer pattern: his code registers with the interpreter to observe function calls.
-
- * before
- * after
- * around (replaces a function by another)
- * stop execution
- * continue execution
-
- Is static interception enough?
-
- ! Use-cases
- Reinhard sees the possibility of customizing apps without modifying them.
-
- Authentication could be another use.
-
- !Wrapping Approach
- Decorator Pattern - actually intercept function calls by delegating them to the original code after "pre-processing".
-
- Stefano: Wrap a flowscript?
- * Call my starting code
- ** Excecute the wrapped FlowScript
- * Call my ending code
-
- Decorator vs. Observer pattern discussion.
-
-
-
-
-
-
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonJsr170 , version: 1 on Mon Oct 6 12:12:41 2003 by BertrandDelacretaz
New page created:
+ Raw notes taken collaboratively during the talk.
+
+ Stay tuned..
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Hackathon , version: 98 on Mon Oct 6 12:11:41 2003 by BertrandDelacretaz
- ! Introduction to the Java Repository API (David Nuescheler, JSR-170 Spec Lead)
+ ! [Introduction to the Java Repository API|GT2003HackathonJsr170] (David Nuescheler, JSR-170 Spec Lead)
? + +++++++++++++++++++++++