Hi Pedro,
this is exactly the kind of thing distributed actors are designed for.
I believe we'll have a rising number of cross-process use-cases which we'll want to support with a system like this. The recently posted "crash tests in swift testing" would also benefit from this, as would other use-cases.
It would be greatly beneficial if we can collaborate on a single "ProcessSystem (: DistributedActorSystem)" which simply isolates some work using spawned processes and allows monitoring their failure, and on top of that we'll build the specific use-cases, be it in swift-testing or what you just explained for general swift CLIs etc.
I'm planning to provide more documentation on implementing distributed actor systems soon, but in general taking a stab at implementing DistributedActorSystem where the remoteCall is implemented by piping messages to a child process is a good start!
I'll try to make a PoC soon as well, but cannot promise timelines -- if you'd like to have a head start on this that'd be awesome. In general you can imagine the usage being something like this:
Please don't hesitate to ping me with questions about distributed actors!
I am wondering if we should do a very basic ProcessSystem that ONLY does spawning processes and monitoring for failure, along with delivering remote calls to them. And on top of that build the ProcessPlugin mini library. This way the plugins can reuse the process stuff from the actor system, and other applications which want distributed actors in processes can as well, even if they're not necessarily the "plugin style".