Ideally we need to remove most of our env vars from /run to /init, I agree. But wouldn't it be a breaking change then?
Coming back to my original question, I'm ok with leaving the env vars on the root level of the json object. I think Carlos already has PRs that could enable that functionality. regards, Vadim. On Mon, Aug 6, 2018 at 11:35 AM Chetan Mehrotra <[email protected]> wrote: > So far I was only thinking to pass in state like we do currently as json > string. But yes we can improvise that and pass in a proper language > specific instance with defined interface. Also in addition to state it can > have some methods attached to it. > > This would also reduce the slight overhead (and boilerplate logic) of json > marshalling and unmarshalling. > > Chetan Mehrotra > > > On Mon, Aug 6, 2018 at 2:34 PM Markus Thömmes > <[email protected]> wrote: > > > I guess this is the famous "context" object, that some other platforms > > use in their function signature? @Chetan is that what you're referring > > to in option 2? > > Am Mo., 6. Aug. 2018 um 10:58 Uhr schrieb Chetan Mehrotra > > <[email protected]>: > > > > > > > What are you thinking as an alternarive? > > > > > > There can be 2 ways > > > > > > 1. Make them part of request json itself say by placing them under > > > `_ow_env` key > > > 2. Or introduce a new explicit env param to the run method call > > > > > > #1 would be compatible. We can also introduce some convention for such > > > system generated values like start with '__' or '__ow_<key name>' etc > to > > > avoid collision in future for such changes > > > > > > Chetan Mehrotra > > > > > > > > > On Mon, Aug 6, 2018 at 2:14 PM Rodric Rabbah <[email protected]> wrote: > > > > > > > > > > > > Should we reduce dependency on env variable to communicate such > > state? > > > > > > > > Oy. That’s right the activation id and deadline will conflict. What > are > > > > you thinking as an alternarive? > > > > > > > > -r > > >
