Thanks Matt - will have a look and report back here if anything comes up. Cheers Michael
On 11/01/17 22:23, "Matt Rutkowski" <mrutk...@us.ibm.com> wrote: >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 <mma...@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" <rod...@gmail.com< >mailto:rod...@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 > > > > >
