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 ?
You need a resource to find an actuator so just poll the same resource for status updates - that is, we can have a verbose text status field in addition to the enum. To clarify:
- Actuators that act immediately will return 200 OK.
- Those that don't will return 202 Accepted.
- Those that create a resource will return 201 Created with a Location: header pointing at the newly created resource (where that could presumably be a feed of resources if you asked for multiple instances).
Ok by you?
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.
It just means you need to pass parameters to the actuator via a GET or POST request (GET comes to mind first but POST works with more/larger parameters)... these exceptional cases can go in the registry... for start it might be 'min-instances' and 'max-instances' for example.
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 ?
I'm still having trouble making this reconcile - force people into your model and you are sure to break something for someone, unless you make it so high level as to be meaningless. sub-classing and categories have the same result - multiple actuators bundled under one heading... if I want to stop the device do I press "shutdown", "halt", "acpioff", "poweroff" or just choose one at random? Better bet is to let implementors make sensible decisions like "try shutdown, wait a minute then do acpioff followed by poweroff if we're still not where we want to be"... think of the "Force Quit" and "End Task" options in windows.
States that don't fit are things like "archiving", "restoring", "backing up", "cloning", "transferring", "transforming"... who's to say there's not going to be a "teleporting" state one of these days?
It won't be anarchy and even if it were we'd just add some constraints... in any case we won't know until we suck it and see.
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 ?
Providing a link to a feed of syslog/eventlog style entries is something that I had envisaged, and doing something similar for state changes/requests (even as a subset of same) does sounds sensible.
Sam