Open Stack

On 14 Feb 2014, at 15:02, Dmitri Zimine <dz at stackstorm.com> wrote:

> Current DSL snippet: 
> actions:
>    my-action
>       parameters:
>           foo: bar
>           response: # just agreed to change to 'results’ 

Just a note: “response” indentation here is not correct, it’s not a parameter called “response” but rather a property of “my-action”.

>               select: '$.server_id'  
>               store_as: v1
> 
> In the code, we refer to action.result_helper
> 
> 1) Note that response is not exactly a parameter. It doesn't doesn't refer to data. It's  (query, variable) pairs, that are used to parse the results and post data to global context [1]. The terms response, or result, do not reflect what is actually happening here. Suggestions? Save? Publish? Result Handler? 

For explicitness we can use something like “result-handler” and initially I thought about this option. But I personally love conciseness and I think name “result” would be ok for this section meaning it defines the structure of the action result. “handler” is not 100% precise too because we don’t actually handle a result here, we define the rules how to get this result.

I would appreciate to see other suggestions though.

> 2) Whichever name we use for this output transformer, shall it be under parameters?

No, what we have in this section is like a return value type for a regular method. Parameters define action input.

> 3) how do we call action/task parameters? Think 'model' (which reflects in yaml,  code, docs, talk, etc.)
>    input and output? (+1)
>    in and out? (-1)  
>    request and response? (-1) good for WebServices but not generic enough
>    parameters and results? (ok)

Could you please clarify your questions here? Not sure I’m following...

> 4) Syntax simplification: can we drop 'parameters' keyword? Anything under action is action parameters, unless it's a reserved keyword, which the implementation can parse out. 
> 
> actions:
>    my-action
>           foo: bar
>           task-parameters: # not a keyword, specific to REST_API
>               flavor_id:
>               image_id:
>           publish:  # keyword
>               select: '$.server_id'  
>               store_as: v1

It will create problems like name ambiguity in case we need to have a parameter with the same names as keywords (“task-parameters” and “publish” in your example). My preference would be to leave it explicit.

Renat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140214/352081f9/attachment.html>