Thanks for the clarification, Karl. I was thinking that I didn't express
this very well.
-- Chris
On 28/11/06 19:37, "Karl Czajkowski"
If I am not mistaken, I think there is a mismatch between Paul's expected use of the state machine and the (perhaps underspecified) assumptions of the BES authors.
I think the BES authors are taking for granted an idiomatic "Grid monitoring" viewpoint which emphasizes steady-state conditions as descriptive summaries of past activity, while downplaying the transitions or transient events. The BES implementation might have actions associated with transitions, but the main monitoring view is meant to be the conditions between events.
In other words: we do not usually assume that the client viewed all transitions, but that he wants to be able to determine the relevant actionable state from a single view of the "current steady state". There are a variety of reasons for this, including a more self-healing distributed system (observer and observed can converge to stable conditions) and more efficient aggregation and indexing (observer can export a meaningful merged model of many resources' conditions).
I think this condition/event dichotomy is the gut reasoning behind both wanting multiple container-level termination states and not wanting self-transitions on a state. As a condition, if you started in the state and ended in the state with no intervening state, then you never left the state, as it is impossible to not be in some state!
As a client, I will not get a stream of "self transitioned" events with any descriptive information. What Chris suggested is to indicate sub-conditions to indicate, in a more domain-specific way, how the system really did change temporarily to another observable steady-state condition, one that could still be interpreted as Pending in the overall condition model.
karl