while this looks cool, this is also getting out of hand. we need an operating system that doesn't require all this machinery on top in order to achieve basic encapsulation.
They couldn't have made the client stub interface more baroque if they tried. It sounded like something that could mimic something approaching the original library interface automatically, pretty disappointed it's basically just another RPC stubs generator<p>If you can stomach the perf tradeoffs, compiling to WASM is much easier than this
When I initially read the description, I thought this could provide a drop-in runtime-linked shared library stub, but looking deeper in the docs and examples it appears there is at least some setup code required on the client side?<p>Can this log the RPC calls around the target C library? Or potentially even replay calls in isolation? The latter could be expensive for non-trivial programs (require saving all synchronized memory state?), but might be more viable with binary diffs of the shared state if the client side doesn't modify the synchronized memory too much.
Most of the problems in creating services by wrapping libraries in RPCs, in my experience, come from most libraries not supporting asynchrony, timeouts etc.<p>The zlib example is a bit baffling to be honest. If zlib goes in to an infinite 100% CPU loop, perhaps due to a zip bomb, you're still screwed as far as I can tell<p>A full RPC abstraction also gives you the opportunity to change out the backend implementation that this doesn't.