openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <mma...@adobe.com>
Subject Re: Passing a context object to actions
Date Mon, 16 Jan 2017 17:38:36 GMT
Thanks Matt - will have a look and report back here if anything comes up.

Cheers
Michael



On 11/01/17 22:23, "Matt Rutkowski" <mrutkows@us.ibm.com> wrote:

>Hi Michael,
>
>I should chime in here...
>
>Part of the "packaging specification" work we are doing (under the 
>openwhisk-wskdeploy tool/repo) seeks to provide a YAML descriptor of OW 
>packages (incl. Actions, Feeds, Triggers, Event Providers, etc.) including 
>a description of an actions expected inputs and outputs (optionally typed 
>and constrained).  This would be used by tooling (and validation) 
>components in order to confirm if Actions that are composed (currently 
>sequenced) are compatible.  We have discussed the possibility of also 
>using the information to provide inter-sequence (platform provided) 
>"massaging" of types/names in order for a more automated way to connect 
>Actions without forcing a clone/fork/rewrite.
>
>In addition, we provide a manifest file that tells the tool where to 
>"pull" input values from, provide credentials for external services (as 
>well as define their signature and location/protocol).  Perhaps you could 
>review this work and provide feedback?
>
>Kind regards,
>Matt 
>
>
>
>From:   Michael Marth <mmarth@adobe.com>
>To:     "dev@openwhisk.apache.org" <dev@openwhisk.apache.org>
>Date:   01/11/2017 08:51 AM
>Subject:        Re: Passing a context object to actions
>
>
>
>Hi Rodric,
>
>Re
>
>This has come up before. The reason the signature of actions is dictionary
>-> dictionary is for action composition. If your signature is (dictionary,
>dictionary) -> dictionary, you cannot compose actions into a sequence for
>example. One of the tenants of the underlying programming model is that
>composition, as with any programming language, is a fundamental feature.
>
>This is an interesting aspect. Do you happen to have a link to these 
>previous discussions? Would be great to read up on the arguments.
>
>Thanks!
>Michael
>
>
>On 07/01/17 03:13, "Rodric Rabbah" <rodric@gmail.com<
>mailto:rodric@gmail.com>> wrote:
>
>   * The fact that we need to unpack the request body and change it has an
>impact on performance
>
>Why? Let the event payload be E, and the request context C, you can pass 
>to
>your action a new dictionary { “event” -> E, “context” -> C }. The gateway
>doesn’t need to decode E and can treat it as an opaque value. Can you
>clarify why the request body must be unpacked?
>
>   * If we want to send binary payloads in a special format, the API
>Gateway or some other process in the middle has to know how to
>decode/encode that payload/Content-Type. So we're limited to what these
>intermediary processes know.
>
>See above, you don’t need to add to the event payload, you can box and
>decoration in the new object.
>
>The same thing happens with default action parameters; they get merged
>with the event. Basically besides the event itself there's no other way to
>configure the action with extra params or pass it a context.
>
>OpenWhisk actions, as functions, have the signature f: dictionary ->
>dictionary. You can modify the dictionary any way you like. So if your 
>want
>to encode a function that receives three parameters g(E, C, P) where P are
>bound params, isn’t this equivalent to a dictionary with three properties
>for each argument? The mapping is isomorphic.
>
>AWS Lambda allows a similar mechanism to pass a "context" to a function.
>In OpenWhisk actions the main method signature would allow 2 params
>instead of 1 (as it is today) and it could look like: function main(event,
>context)
>
>This has come up before. The reason the signature of actions is dictionary
>-> dictionary is for action composition. If your signature is (dictionary,
>dictionary) -> dictionary, you cannot compose actions into a sequence for
>example. One of the tenants of the underlying programming model is that
>composition, as with any programming language, is a fundamental feature.
>
>And really what is a context other than just an added property? Can you
>show me a case where boxing an opaque value into another dictionary 
>doesn’t
>give you the feature you want?
>
>If you start going down the road of changing the action signature, then I
>think you have to buy into a much more disruptive idea, where the 
>signature
>of a method implies legal vs illegal compositions, and perhaps even admit
>typed parameters.
>
>-r
>
>
>
>
>
Mime
View raw message