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@merzky.net
> <mailto:andre@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@ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg