At this stage, I think for the "openwhisk protocol 0" (that I am going to write down and document), I plan to just follow your suggestions:
- get rid of the handshake - output to channel 3 ALSO for Go (it solves a possibly non deterministic section in the code) For future expansions we can think of the protocol version again, especially for streaming, where the whole initialization and termination is more important (they become long running processes) -- Michele Sciabarra [email protected] On Sun, Mar 11, 2018, at 2:02 PM, Rodric Rabbah wrote: > Continuing on my earlier post about the native function interface, and > following up on the latest changes as suggest by Vadim, i wanted to also > point out that the /init protocol today is synchronous, whereas to do > validation on the binary or to exec a new process, it’s worth > considering an asynchronous handoff. > > So one thought is to augment the protocol to allow /init to initiate the > new binary (load it, exec it) and a /ready to poll which waits for a > response. This bring you closer to the original prototype where you > exec’ed the binary. > > It also makes for a consistent protocol for a native Functions with > their own builtin proxy (go, swift, rust, and also has less copying of > data at runtime), and later can be adapted for a native function like a > bash script which needs a proxy to relay payloads and results. > The /init equivalent for the latter is starting the script, and /ready > is waiting for {openwhisk: 1}. > > -r
