callback is gone in newer node versions in AWS lambda and you can return a promise which makes the difference between the lambda and openwhisk signature specific to context.
Note that lambda is less uniform in signatures and models across languages. Annoyingly. -r > On May 7, 2019, at 8:28 AM, James Thomas <[email protected]> wrote: > > I'd definitely prefer to see us have a more generic discussion on changing > all runtimes to provide the context as an invocation parameter, rather than > having per-runtime fixes. This doesn't affect the invokers AFAIK. > > Moving to providing a second `context` argument would have the advantage of > mirroring other serverless platforms, e.g. AWS Lambda. > > exports.*myHandler* = function(event, context, callback) { > *... function code* > callback(null, "some success message"); > // or > // callback("some error type"); > } > > > >> On Thu, 2 May 2019 at 18:11, Rodric Rabbah <[email protected]> wrote: >> >> I agree that any such change doesn’t need to touch the invoker except to >> potentially remove one variable from the environment (api host). >> >> >> -r >> >>> On May 2, 2019, at 12:11 PM, Tyson Norris <[email protected]> >> wrote: >>> >>> FWIW, I don't think of this as a huge change, meaning no change is >> required at invoker/controller. Rather it is just a convention for context >> value access within functions and function signature that is already unique >> to each language runtime, and requires possibly supporting 2 runtimes per >> language+convention while transitioning to the new convention. This >> convention is exposed to function developers so "replacing it" is not >> really an option, I think, but rather requires graceful deprecation and >> migration (with developers participation). >>> >>> e.g. for nodejs, the old convention used for signature and context is: >>> - function signature is `<function> (args)` >>> - context is `process.env.<context key>` >>> >>> New convention for signature and context is: >>> - function signature is `<function> (contextObject, args)` >>> - context is ` contextObject.<context key>` >>> >>> So you can feasibly: >>> * create a new runtime for nodejs that uses new convention >>> * add a separate kind for using the new runtime >>> * gradually phase out use of old kind (communication, deprecation, etc) >>> >>> I just want to throw this out there because I get the feeling whenever >> we discuss "context" that there is misconception around the need to change >> the invoker to support this. There is surely some parts of the >> invoker/action container protocol that may be further cleaned up to isolate >> static values (action name) from per-activation context (activation id), >> but I don't think that is required to start changing the conventions for >> function signature to include context as a separate object from activation >> params. >>> >>> Thanks >>> Tyson >>> >>> >>> On 5/2/19, 8:54 AM, "David P Grove" <[email protected]> wrote: >>> >>> >>> >>> Rodric Rabbah <[email protected]> wrote on 05/02/2019 11:05:35 AM: >>>> >>>> any existing java function that uses the environment variables would >> have >>>> to be modified. >>>> i would not change it - openwhisk has a uniform model across all the >>>> runtimes and this would start to diverge... i can be convinced but >>> instinct >>>> is to leave it alone. >>>> >>> >>> I think the change could be justified if it was part of a broader >> redesign >>> to enable concurrent activations in a runtime. >>> 1. pass in a context object instead of stashing >> activation-specific >>> params in the environment >>> 2. require proper structured logging >>> >>> --dave >>> >>> >> > > > -- > Regards, > James Thomas
