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 >
