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

[Sam Johnston]

On Thu, May 14, 2009 at 8:45 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:

> 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.
>

Great, so there's [at least] two of us writing code now - the more the
merrier.


> 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?
>

These sound like great examples as to why we shouldn't try to beat reality
into a fixed state diagram (or vice versa), except perhaps at a very high
level (and even then I have my doubts).


> 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.
>

This is a very good point and something I think is well covered by our
existing (extremely simple) security model: implementors decide what to show
their clients based on who is connected.

This is an example of one of those asynchronous errors not handled by HTTP -
something we're going to have to have a look at in more detail for all
asynchronous actions in due course.

Sam


> 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
> >
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090514/b620325a/attachment.html