On 14 May 2009, at 10:59, Alexis Richardson wrote:

+1 to Sam's "we may need to revisit this point in the name of interop"

I'm not sure if this is *just* an interop thing ...

I thought my suggestions yesterday on how to transition state, error reporting, handling 'processing' states, etc ... were reasonable.

Kind of disappointed this morning that I didn't get some feedback from you guys ... :(

Roger, I was working on OCCI until 5am this morning and while this is by far the most interesting part of the work it's only half of the problem. The other half, adoption/marketing, is boring grunt work that keeps us organisers very much on our toes, preventing us from being responsive at times.

In particular the absence of consensus around formats has put me in a fairly awkward position for my scheduled talk at Prague on Tuesday (which was due yesterday) and is jeopardising previously agreed deadlines that I have been advertising heavily in my own name. It doesn't help that I don't really share your concerns about states being a problem and am confident both that what we have will work and that it will invariably be refined in due course.

Thanks for your understanding - I think you would be surprised to see how much behind-the-scenes work goes on in constantly driving this kind of initiative forward, which is why one has to be 100% committed to, and believe in, the cause.

Sam

At this stage we are shooting for a draft. The draft will let people
implement prototypes which will let us debug interop and refine the
model.

On Thu, May 14, 2009 at 10:55 AM, Sam Johnston <samj@samj.net> wrote:

On Thu, May 14, 2009 at 10:23 AM, Andre Merzky <andre@merzky.net> wrote:

Quoting [Sam Johnston] (May 13 2009):

Yes, me, I don't think HATEOAS should be applied in this
context. But I realise/accept that I maybe the only one
with that opinion - thats ok. So I'll say it here one last
time, for the record, and then will shut up: "a static
simple state model allows for very simple clients.
Extensions can be defined via substates, or additional
transitions."

I would counterargue that HATEOAS allows for even simpler clients
because they don't have to worry about hardwiring even a simple state
model. Using HTTP we can even feed them plain $LANG descriptions of
what the transitions and targets are - it doesn't get any easier than
that and you don't have to worry about updating clients to implement
new goodies.

I don't see that. If I want to write a client tool which
starts a resource, I want to make sure the resource is in
RUNNING state when the client reports success. But if that
client (a) has to infer the available states from a
registry, it cannot posisbly know which state has the
semantic meaning of RUNNING attached. Further (b), if the
client only sees those state transitions it is allowed in
its current state, how does it know what transition path to
take to reach that target state? Is it (I am making those
up obviously):

INITIAL -> create() -> CREATED -> elevate() -> ELEVATED () -> run() ->
RUNNING

or

INITIAL -> create() -> CREATED -> init() -> INITIALIZED -> run() ->
RUNNING

Or should the tool simply fail because it cannot see a run()
transition in its INITIAL state?

The client must at least know how to create a resource and when it has done
so successfully a "start" actuator will appear, perhaps with a target state
of "running" (TBD). In that case it knows that if it pulls the "start"
handle eventually the resource should end up "running". Otherwise it could
know (from the registry) that "start" is the right button to push, but
that's starting to break HATEOAS principles. We have options - it's just a
matter of finding the right one.

I think HATEOAS works pretty well if a human is in the loop
who can parse the available transition description, and
deduce a semantic meaning. I don't think it makes for
simple tooling, really.

I agree that humans are better at this stuff than computers but I'm
unconvinced this translates to complex tooling.

Then again, I may misunderstand the proposed usage of
HATEOAS in OCCI. So, can you help me out: what mechanism
will avoid the confusion from the example above, if a vendor
can provide init() and elevate() transitions on the fly,
with no predefined semantics attached? How would my tool
deduce the transition path it needs to enact?

The semantics for common functions will be in the registry. It's ones that
are uncommon and impossible to predict like "translate" and "migrate" that
we're catering for here, and generally there will need to be some kind of
client side support for these.

As I said below, "we may need to revisit this point in the name of interop",
and I suggested categories as one possible solution (e.g. a "starting" vs a
"stopping" transition)... parametrised transition calls are another... for
example, how do I tell something to start *without* saved state if saved
state is present (ala cold start vs resume)?

Sam

I don't think anyone knows every possible thing that users are going
to
want to do with the API (I certainly don't have the confidence to say
I
do anyway) but we may need to revisit this point in the name of
interop... Atom categories would be one way to achieve this (e.g.
"Cold
Reboot" and "Warm Reboot" might go in the "restart" category).
Sam

References

1. mailto:andre@merzky.net

--
Nothing is ever easy.

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg

Roger Menday (PhD)

<roger.menday@uk.fujitsu.com>

Senior Researcher, Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
Tel: +44 (0) 208 606 4534

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