openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragos Dascalita Haut <ddas...@adobe.com>
Subject Re: Passing a context object to actions
Date Mon, 09 Jan 2017 19:02:57 GMT
Rodric, thanks for sharing more info. I've been thinking at it over the weekend.


I'm reading in the Gist comment that the idea is to do:

 1. json_data.event = data;

 2. json_data.context = ...


I'm wondering what do we do when "data" comes in a binary format. Binary formats could easily
come into play if I think of ML, big data scenarios, and others. If the intent is for OpenWhisk
to convert all events into a JSON format then it could probably mean we'd have to convert
the binary to hex ending up with something like this:

1. json_data.event = convertToHex(data)

2. json_data.context = ...

I'm not sure this is the most efficient solution from the performance perspective. Users would
not be able to benefit from the optimizations brought by various protocols (i.e. protobuf).

> The gateway doesn’t need to decode E and can treat it as an opaque value.

Let's say the Gateway can do this. There are still a few aspects to be taken into consideration:

- The Gateway would have to allocate memory to copy the payload into the new object wrapping
the event + the context , provided the event (binary or not) is sent as a "string".

- The Gateway wouldn't be able to stream the event payload, but it would have to buffer it
first so that it can read it and then change it. In HTTP the headers are sent first and could
be read first; this creates an opportunity for performance improvements b/c not only the request
could be validated without reading the body, it could also be stopped earlier if it's malicious.
And when it's valid the Gateway could decorate the request with extra headers for the context
(which would also be sent ahead of the body) then start streaming the body directly from the
client.

> if you 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?

Yes from this perspective it's a fine difference. OpenWhisk internally could choose to use
this idea too and keep the E, separated from C and P. This is where it gets arguable whether
this is the best way to communicate the intent; I have to admin that probably b/c I'm used
with working with a "context" object I'm more biased towards it; subjectively speaking it
feels more natural for me and the performance aspects make me even more biased.

> 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.
I think I need some help to understand how a context object could prevent Openwhisk to trigger
actions in a sequence.

I'm also adding an extra thought to our thread: if we want to communicate a "user_id" and
"app_id" to the actions, but any action can edit the incoming event, how would we make sure
that some important fields like these ones can't be overwritten by other actions in a sequence
and they can be securely passed through and trusted ?

Thanks,
dragos
________________________________
From: Rodric Rabbah <rodric@gmail.com>
Sent: Saturday, January 7, 2017 8:25:32 AM
To: dev@openwhisk.apache.org
Cc: dev@openwhisk.incubator.apache.org
Subject: Re: Passing a context object to actions

I added a comment to your gist (https://gist.github.com/ddragosd/
3afd5d8678e5dbda48b943a1125aad0c#file-zcloudfront-conf-L71-L93) that
reflects my comments about boxing the event.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message