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 Wed, 11 Jan 2017 14:51:19 GMT
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