[occi-wg] OCCI MC - State Machine Diagram

[Andre Merzky]

Quoting [Sam Johnston] (May 13 2009):
> 
>>   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."
> 
>    I would counterargue that HATEOAS allows for even simpler clients
>    because they don't have to worry about hardwiring even a simple state
>    model. Using HTTP we can even feed them plain $LANG descriptions of
>    what the transitions and targets are - it doesn't get any easier than
>    that and you don't have to worry about updating clients to implement
>    new goodies.

I don't see that.  If  I want to write a client tool which
starts a resource, I want to make sure the resource is in
RUNNING state when the client reports success.  But if that
client (a) has to infer the available states from a
registry, it cannot posisbly know which state has the
semantic meaning of RUNNING attached.  Further (b), if the
client only sees those state transitions it is allowed in
its current state, how does it know what transition path to
take to reach that target state?  Is it (I am making those
up obviously):

  INITIAL -> create() -> CREATED -> elevate() -> ELEVATED () -> run() ->  RUNNING

or
  
  INITIAL -> create() -> CREATED -> init() -> INITIALIZED -> run() -> RUNNING

Or should the tool simply fail because it cannot see a run()
transition in its INITIAL state?

I think HATEOAS works pretty well if a human is in the loop
who can parse the available transition description, and
deduce a semantic meaning.  I don't think it makes for
simple tooling, really.

Then again, I may misunderstand the proposed usage of
HATEOAS in OCCI.  So, can you help me out: what mechanism
will avoid the confusion from the example above, if a vendor
can provide init() and elevate() transitions on the fly,
with no predefined semantics attached?  How would my tool
deduce the transition path it needs to enact?

Many thanks, Andre.


>    I don't think anyone knows every possible thing that users are going to
>    want to do with the API (I certainly don't have the confidence to say I
>    do anyway) but we may need to revisit this point in the name of
>    interop... Atom categories would be one way to achieve this (e.g. "Cold
>    Reboot" and "Warm Reboot" might go in the "restart" category).
>    Sam
> 
> References
> 
>    1. mailto:andre at merzky.net



-- 
Nothing is ever easy.