[WIKI-UPDATE] GT2003HackathonFlow Wed Oct 8 12:00:03 2003

[st...@outerthought.org]

Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonFlow , version: 4 on Wed Oct  8 09:08:53 2003 by MarcPortier

+ (sorry, to say the 'test' didn't happen. However we shouldn't panic on this: I really think  it's a very rare case that would get us into the race conditions with current flowscript stuff and as Stefano was saying: if real time applications are not providing the tests that let the possible race conditions surface, then making the test probably only has academic value)
+ 
+ Original text:
+ Update: (mpo) Well, reading the above I even don't understand it, so I guess I was quite succesfull at being completely misunderstood :-)
+ The word 'use-case' indicates that the bigger goal behind things is to enable a 1-1 technical coding of the use case emerged from the analysis fase.  So it really is the UML use-case as being {{<< the written down set of pre-conditions/post-conditions and intermediate interaction-steps with external users and systems >>}} but written down in a formal programming language so it can really be executed.  I like this 1-1 mapping back to how analysts perceive the system to be broken down in pieces of atomic behaviour.  IMHO the real goal of a system that declares itself as MVC would be that it allows more then anything else to cater for a (one) "controller" which is really just that (and thus the use case written down as an atomic executable piece of the system, in our world logically an avalon component)
+ 
+ Now where is the sub-tree confusion comming from?  Well, basically I did a clumsy job at trying to explain what is different between apples and flowscript in respect to maintaining the actual 'state' you 'use-case' (or controller) is in.  See: in both cases the controller is guiding the user through the different interactions that make up the use case... we could look at each interaction-moment as some kind of wait-point (waiting for the user to 'complete the form, folow a link, in general: 'to continue the use case') Now these 'wait-points' are actually to be seen as finite states of your controller IMHO. They comprise 'where you are in the flow, what has been entered up to know, intermediate results achieved,...  Now the (only) (technical) difference between flowscript-interpreting and apple-processing is that the first is remembering all the different 'wait-points' and the path of how you got from the one to the other: you get a tree of continuations, each with their ow!
n unique id.  The complete set of them is holding the knowledge of how the end-user stepped through the use-case. That led me to say: "The complete state of the use-case (or put different: the knowledge we have about the user stepped through all interactions) is inside the tree of continuations."
+ 
+ While in the case of apples we are remembering a lot less: only the last wait-point, or the current state.  (comparing back to flowscript this is as if you would invalidate every continuation upon use, and since you only have one continuation at each time would decide to have them all use the same continuation-id rather then allocate new ones, which must sound horrific to flowscript peeps but really explains the difference on a technical level)
+ 
+ Too me, there is no magic either way ;-)
+ 
+ 
+ Original text:
+ 
+ 
+ Update: (mpo) actually the argumentation behind the proposed name changes is based on the contract between the sitemap and the flow. Putting up the hat of the URI-focus, and what the sitemap sees is two kinds of URI's: fixed ones, known upfront that point to a use case to start, and then the dynamic or temporary ones, carrying the continuation-id to point to the 'temporary resources' that store the wait-point info that allows to continue the use case.
+ 
+ So in fact may name change proposal indicates the sitemap should carry semantics which are in his URI-focussed realm. I consider the current ones as being 'biassed' by the interpreter-implementation.  It's a somewhat purist way of pointing out possible 'mixing of concerns' Admittedly more at the conceptual and 'how we think about it' level then anything else.
+ 
+ 
+ Update: (mpo) The response to this really is asking it the other way around, so I jokedly replied 'why not' but honestly the return question is "Why would I save all wait-points if my app doesn't need that?"
+ 
+ 
+ 
+ 
+ Update: (mpo) agreed, it's just a different aspect that gets added over and over again to multiple applications, so from that perspective there remains some stress to think about factoring the concern out so it becomes reusable across apps. This is however not an argument to just put in into the continuations-manager.
+