On Thu, May 14, 2009 at 1:17 PM, Roger Menday <roger.menday@uk.fujitsu.com>wrote:
On 14 May 2009, at 11:55, Alexis Richardson wrote:
Roger
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
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.
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. Sam