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 > >
