cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [WIKI-UPDATE] GT2003HackathonFlow Wed Oct 8 12:00:03 2003
Date Wed, 08 Oct 2003 10:00:03 GMT
Page: , 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
+ 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.

View raw message