[occi-wg] OCCI MC - State Machine Diagram

[Roger Menday]

Sam

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

I think that is a good way.

The thing (that I understand about the actuator) approach, or rather I  
have not seen documented anywhere, was that POSTing to an actuator URI  
doesn't seem to create a resource anywhere. So, we can't do that right  
now.

OK, maybe that is something for OCCI 2.0, but why not do it now ?

> An eventlog extension is another.
>
> - error reporting
>
> As above.
>
> - 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.

So, actuators don't seem to cover this (?)

Modeling state discovery *and* request as part of a model does seems  
to be a good alternative.

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

Yes, but, the people need to conform to some extent. That's why we are  
having this JSON vs ATOM discussion, right ? They also need to conform  
to a basic state model, and then allow states to be specialized if  
necessary. Don't you actually get this if you have  state modeled as  
part of a class model; a simple one that everyone can live with -  
rather like the one in the OGF Reference Model - together with sub- 
classing for more specialist cases ?

So, generically processed by everything at some level. That takes care  
of brittleness, right ?

Roger

ps. Actually, I would've thought that having the state of something as  
a stream of updates inside an feed would appeal to a "atom/atompp for  
occi" proponent ?


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

> Sam
>




______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090514/2b52129d/attachment.html