On 14 Feb 2014, at 15:02, Dmitri Zimine <d...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev