Hi Matt, After reviewing the doc [1]:
* I think parameter passing (and typing of those) in-between actions in a sequence looks similar to the original problem, but it is not quite. I have restarted the original thread on that topic. When it comes to parameter passing for application purposes as described in the spec: I am personally fine with the proposal as is (on the topic of typing parameters). However, if you want to use the descriptor file for tooling as you mention then you probably need an additional flag “required/not-required” for input parameters. In non-tooling scenarios the app developer can implicitly deal with non-required parameters. * while I was at it, I have collected some notes on the doc. Most comments are nit picks or probably misunderstandings on my side. But wanted to pass them here anyway: - It is my understanding that sequences are a more general type of action, meaning that pretty much wherever I can call an action I could as well call a sequence as well. If that’s correct, then it might deserve a sentence or two. I was a bit confused by the absence of sequences in the locations below and wondered if the absence meant that the various statements might not apply for sequences: * line 47: “mapping from a trigger to an action” (can it also be a sequence?) * line 84: "Every OpenWhisk entity (actions, triggers, feeds)” (also sequences?) * line 285: this one being the most important example, because it is normative: can a trigger also apply to a sequence? The spec clearly mentions actions only - line 132: the glossary contains entires that I did not find later on - maybe I missed them. But in particular “project” caught my eye as I expected a construct to organise code (similar to package), but could not find anything later. - line 252: not sure if the list of runtime names should be in the normative section of a spec, because (as you also write) this list will fluctuate between deployments and over time. OTOH there should be established well known names for well-known runtimes. Maybe point to a community-curated, separate markdown file (where new entries get a PR that can be voted upon)? - line 268: I was surprised to see execution limits to be part of the app specification (written by an app dev), but guess it might make sense. However, I still wondered how these limits would compare to limits set by the cloud provider. Is it always the lowest value (provided either by cloud provider or app developer) that would apply? Also in this table: the "valid range”s looked a bit unexpected in a packaging spec (especially the values in that column). - line 274: the example action definition shows a previously unmentioned “version”. (or I missed it before). Is this version more than a human-readable string, ie. does it assume SemVer semantics? If the latter, does deploying a “higher” version implicitly undeploy “lower” versions? Probably, this (versioning) is a more relevant topic and might deserve its own thread... btw: in line 352 a “version” also shows up in the package definition example - same questions as above :) - line 333: feedactions have special administrative parameters like CREATE, DELETE, etc. That’s great - I just wondered why that mechanism is only available for feedactions. Would it make sense to make this consistent and have special CREATE, DELETE (“deploy”, “undeploy”) parameters for each 1st class citizen (action, trigger, etc) in OW? - line 348: wondered what “unlicensed” means. Proprietary? HTH Michael [1] https://github.com/openwhisk/openwhisk-wskdeploy/blob/master/specification/openwhisk_v0.8.pdf On 16/01/17 18:38, "Michael Marth" <mma...@adobe.com> wrote: >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 >> >> >> >> >>
