Guido Casper <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote: >>You can call it whatever you want but a "state" in a FSM and a >>"continuation" in a script are exactly the same thing, they need to >>contain the same amount of data to be able to resort the execution. >> >>The problems in replicating one across containers will be the same >>problems in replicating the other. > > > Hmm, I don't think so. A FSM (in general) and a continued script are > in not isomorphically equivalent in CS terms, so there can be no > equivalence between the maintenance of state and the maintenance of a > continuation. However, for practical purposes, I would agree, they > need to contain more or less the same information.
While this would be true if you are just talking about the continuation ID (while destroying the whole idea of querying the repo for task lists) you actually have to maintain the whole continuation stack.
I think the point was that the "extended state path list" and the continuation stack would work out to the same thing. But maybe I'm missing something...
I mentioned using a state path to store the current state, but I intended it a bit different then used here. Wat I actually meant was a state identifier (or set of identifiers for concurrent states). An example of a state identifier (using the diagram from the first post) is: /Existing/Reviewed/Published. This is enough information to restore the workflow instance, because like I said previously the transition history cannot affect the processing taking place at a state.
Using state identifiers also makes it (relatively) easy to migrate to a new workflow definition. Either the new definition has states with identical identifiers, or the new definition can have a mapping from old state identifiers to new state identifiers.
Other information needed for proper processing should be stored with the object.
-- Johan Stuyts
