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.