openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Rutkowski" <mrutk...@us.ibm.com>
Subject Re: Passing a context object to actions
Date Wed, 11 Jan 2017 21:23:29 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message