[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

On Wed, May 13, 2009 at 10:08 PM, Andre Merzky <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/537d89b2/attachment.html