Great proposal, looks like a really good solution to the challenges discussed. Looking foward to seeing this in action.
On 15 February 2018 at 20:20, Michele Sciabarra <[email protected]> wrote: > I spent some time thinking about my proposal to support Go Actions, and I > tried to address some weaknesses that emerged in the discussion (again, thank > to James Thomas for pointing them out). > > First, the most relevant, my approach requires you implement a supporting > library able to run an http server in each language you want to support. So > one for Swift, one for C/C++ (why not?), even one for Rust or D or Haskell or > whatever. While it is relatively simple, it is definitely not a generic > solution for supporting binaries. > > Second, there are some secondary problems: a “race condition”, when I upload > an action, the current server will be closed so it won’t serve actions. For > a very small amount of time, but it happens. Also I have some concerns about > what happens if the user does not upload a proper executable. It could break > the runtime, so some validation is needed. > > I hence decided to raise the bar and think to a better implementation. My > updated proposal is now an extension of the current implementation, but using > a pipe and keeping the "child" process running to serve actions, not > terminate and be started again at each request. > > Instead of “exec” we should launch a process and pipe input, output and > error. The process however should not be expected (as it is now in Docker > actions) to read the standard input, write some logs then a serialised json > objects and then terminate. > > Instead, the uploaded binary should be expected to: > > * read continuously the standard input line by line > * interpret a single line as a serialised json object > * write logs IN THE STANDARD ERROR > * write the answer in the output as a single line > > In this way we can basically use all the compiled languages using just the > standard libraries. It will behaves like a standard command line function. > Well, almost (it still will have to encode and decode json). > > A controlling process (of course done in Go) will receive a “/run” request , > then it will feed to the process, read his answer and then return the answer. > > The implementation is basically an extension of what I already coded in Go > (no code to throw away). It is just a bit more difficult... > > How does this updated proposal sound like? > > -- > Michele Sciabarra > [email protected] -- Regards, James Thomas
