[occi-wg] OCCI MC - State Machine Diagram

[Andre Merzky]

Quoting [Sam Johnston] (May 13 2009):
> 
>>> That was exactly the point of introducing both together - given that
>>> most of the innovation is going to happen server side, clients
>>> should be as dumb as possible. That is, it doesn't matter if a new
>>> state comes along after a client has shipped because it will be
>>> advertised as a potential transition (HATEOAS), perhaps even with
>>> the expected target state.
>> 
>> I totally agree.
> 
> Great. Anyone doesn't agree with the need for [and proposed solution
> offering] flexibility in the state model?

Yes, me, I don't think HATEOAS should be applied in this
context.   But I realise/accept that I maybe the only one
with that opinion - thats ok.  So I'll say it here one last
time, for the record, and then will shut up: "a static
simple state model allows for very simple clients.
Extensions can be defined via substates, or additional
transitions."

Best, Andre.


> 
>      The temptation is to assume that infrastructure is a simple problem
>      with a fixed domain but I can assure you this not the case - without
>      allowing for such flexibility each implementor will find themselves
>      having a good chance of running into functions they are not able to
>      expose via the API, or which the API expects but which are not
>      present (for example, if "stop" implicitly results in "destroy"
>      should we offer "stop" at all?).
> 
>    My point was I wanted to talk about the "states as verbs" model which
>    currently on the wiki ...
> 
>    So the question is do you ask a "RUNNING" resource to "STOP" by
>    pressing a button in order to get it to the "STOPPED" state or do you
>    update its status from "RUNNING" to "STOPPED". To me the latter is
>    unclean because who are you to say you're going to get to that state
>    immediately, or indeed that you'll even get there at all - updating the
>    status of a "STOPPED" machine to "RUNNING" makes no sense if there's an
>    operating system error that causes the boot to fail for example. I
>    certainly prefer pressing a "START" button, having a transitional
>    "STARTING" state with an accurate progress indicator and eventually
>    reaching a "RUNNING" state. There's some sense in a parametrised
>    "transition-to" function of some sort with an array of potential target
>    states but I still think I prefer the actuator approach that we
>    currently have.
>    Sam
> 
> References
> 
>    1. mailto:roger.menday at uk.fujitsu.com
>    2. mailto:roger.menday at uk.fujitsu.com



-- 
Nothing is ever easy.