[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

On Wed, May 13, 2009 at 3:40 PM, Roger Menday
<roger.menday at uk.fujitsu.com>wrote:

> > I am not feeling comfortable with having a state model which
> > will change on the fly, depending what a resource will
> > answer.  For one thing, it will make user interfaces and
> > tools really difficult to design:
> >
> >  - should I add a suspend button, even if it works only sometimes?
> >  - if it worked once, will it work again?
> >  - what can I do if it does not work?  I want to suspend,
> >    dammit! ;-)
>
> I don't share your pessimism, but then again, I also think we are
> getting our wires crossed. I think there is a lot of help here from
> hateoas which does a lot to address your concerns above (??)


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.

The temptation is to assume that infrastructure is a simple problem with a
fixed domain but I can assure you this not the case - without allowing for
such flexibility each implementor will find themselves having a good chance
of running into functions they are not able to expose via the API, or which
the API expects but which are not present (for example, if "stop" implicitly
results in "destroy" should we offer "stop" at all?).

Like it or not there will be rapid evolution in this space and you only need
to look at what weird and wonderful things people like Google and Cisco are
doing with hardware to realise that we pretty much don't know what we're
talking about today let alone the life of the protocol.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/a3a16ce7/attachment.html