On 13 May 2009, at 15:13, Sam Johnston wrote:
On Wed, May 13, 2009 at 3:40 PM, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
> I am not feeling comfortable with having a state model which
> will change on the fly, depending what a resource will
> answer. For one thing, it will make user interfaces and
> tools really difficult to design:
>
> - should I add a suspend button, even if it works only sometimes?
> - if it worked once, will it work again?
> - what can I do if it does not work? I want to suspend,
> dammit! ;-)
I don't share your pessimism, but then again, I also think we are
getting our wires crossed. I think there is a lot of help here from
hateoas which does a lot to address your concerns above (??)
That was exactly the point of introducing both together - given that most of the innovation is going to happen server side, clients should be as dumb as possible. That is, it doesn't matter if a new state comes along after a client has shipped because it will be advertised as a potential transition (HATEOAS), perhaps even with the expected target state.
I totally agree.
Great. Anyone doesn't agree with the need for [and proposed solution offering] flexibility in the state model?
The temptation is to assume that infrastructure is a simple problem with a fixed domain but I can assure you this not the case - without allowing for such flexibility each implementor will find themselves having a good chance of running into functions they are not able to expose via the API, or which the API expects but which are not present (for example, if "stop" implicitly results in "destroy" should we offer "stop" at all?).
My point was I wanted to talk about the "states as verbs" model which currently on the wiki ...
So the question is do you ask a "RUNNING" resource to "STOP" by pressing a button in order to get it to the "STOPPED" state or do you update its status from "RUNNING" to "STOPPED". To me the latter is unclean because who are you to say you're going to get to that state immediately, or indeed that you'll even get there at all - updating the status of a "STOPPED" machine to "RUNNING" makes no sense if there's an operating system error that causes the boot to fail for example. I certainly prefer pressing a "START" button, having a transitional "STARTING" state with an accurate progress indicator and eventually reaching a "RUNNING" state. There's some sense in a parametrised "transition-to" function of some sort with an array of potential target states but I still think I prefer the actuator approach that we currently have.
Sam