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 <rod...@gmail.com> Sent: Saturday, January 7, 2017 8:25:32 AM To: dev@openwhisk.apache.org Cc: d...@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.
