Indeed after thinking about my idea was to try to extend the invoker.py to serve urls, and add a —watch feature so if files are modified then they are zipped and sent to the runtime as /init. Since the go runtime compiles already I think it is better to leave the compilation to the runtime. Another interesting feature of the goproxy is that it supports the “unnecessary” multiple initializations so it should ne able to do incremental compilation at least for go code.Another interesting feature that I am ‘stealing’ from the openwhisk shell is support for debuggers. I will try to make available delve if I can. I suppose it is just enough to be able to run the client executable with delve and expose the debugger port. I think the openwhisk shell is awesome for node but I want something specific for go that works with vscode, and let me run tests on the code as I develop it. And also the go debugger now.I plan to write the miniwhisk for now in Python, as part of the examples for go. Then eventually rewrite it in go if it proves interesting enough to became a standalone tool. Thoughts?
-- Michele Sciabarra [email protected] On Thu, Jul 26, 2018, at 8:54 PM, Rodric Rabbah wrote: > > > My approach was to implement the OpenWhisk platform API > > using a stub server that would execute the actions using Docker in > > the host> > system. > > You really don’t need this though - look at the invoker.py > script. That> is enough IMO, either extending that or copying that into a new > executable (go or node). > > -r
