[occi-wg] OCCI MC - State Machine Diagram Please clarify

[Gary Mazz]

I'm in agreement with Sam on this point.

I have a hard time reconciling the initial state and final state as I'm 
here writing some code.

The initial state is prior to creation (instantiation) of the entity. 
The final state is the state after destruction. The error state also 
leads to a non existence state without a destruction phase.  
Additionally,  there is a destroyed state but no instantiate state Once 
destroyed aren't you at the final state, non-existence ?  You can't have 
a destroyed state if you don't exist to maintain the state.  This state 
table makes sense if you are looking at it from the perspective of a log 
file, but its confusing from the perspective, an object lifecycle 
especially in the case of destroyed without parity to instantiated. 
Trivial as it may appear.

How does restart on error occur in this model ? It appears restart can 
only occur when your active ? When does the active get the start trigger 
or you can't have an inactive event ?  Does the active/restart depict 
the life cycle of the object contents ?

How does the state diagram reconcile restart on error and hold on error 
? Or some other action on error like snapshot?

Second, it may not be appropriate for one type of user to gain access to 
details. A customer may only need to know their "service" is stuck in a 
specific state, while an support engineer may see a more detailed view 
of the state and a development engineer may see another more detailed 
view of the state. You may not want the customer to see all the 
underlying details. A service provider may only want customers to see 3 
states; loading running stopped.

-gary


Sam Johnston wrote:
> On Wed, May 13, 2009 at 10:08 PM, Andre Merzky <andre at merzky.net 
> <mailto:andre at merzky.net>> wrote:
>
>     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 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>