[occi-wg] OCCI MC - State Machine Diagram
samj at samj.net
Thu May 14 06:34:48 CDT 2009
On Thu, May 14, 2009 at 1:17 PM, Roger Menday
<roger.menday at uk.fujitsu.com>wrote:
> On 14 May 2009, at 11:55, Alexis Richardson wrote:
>> What specific points did you most want feedback on?
> Maybe I am getting actuators wrong ... it could be, I like the Sun API, and
> they use actuators. But, actually, actuators don't seem that great, and they
> have filtered down into the verb part of the noun-attribute-verb model. And
> so, I think it is interesting to explore other ways of doing it, which
> address (these overlap)
> - async concerns
Status/error fields would be one simple solution to this problem - we
already have HTTP 20x error codes to indicate that something is indeed
async. An eventlog extension is another.
> - error reporting
> - offering porential of something more than just pressing a button (move a
> few dials then press a button, for ex)
This is likely to be an absolute requirement - I don't want to have to press
the start button 50 times to get 50 instances so there will need to be some
way to create-en-masse for a start (probably with the flexibility of ranges
ala amazon). I may also need to specify cold start vs warm start (e.g. with
or without state). I've not really even started thinking about this yet,
beyond knowing that there are a few potential solutions.
> A different perspective is that in the state should be part of the model,
> not as a enumerable defined in a registry.
Sure, this is the more formal approach but it's also more rigid/brittle. As
we can't hope to predict every state that will ever exist, least of all in a
fashion that is understandable/acceptable to everyone, we need to be
flexible. State diagrams are as much a personal preference, as evidenced by
the many that exist for different projects - Microsoft vs VMware vs DMTF vs
OGF being the ones I've looked at.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the occi-wg