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