openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: Passing a context object to actions
Date Sat, 07 Jan 2017 02:13:17 GMT
>   * 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