Prior to the move to github, we were working on improvements to the inter-component RPC protocol (see declined PR). Part of the motivation for this was better handling of changes to the protocol in a way that could be detected and/or were backwards compatible.

I'd like to propose that we take a further step back and consider whether we want to continue to use own our ZMQ RPC protocol. When we made this decision (at least 8 years ago) the RPC landscape was very different. But there are now mature projects out there for cross-language RPC such as gRPC (initially created by Google). As an example, gRPC requires a well defined protocol document that specific language interfaces are then generated from. It also supports bi-directional streaming during specific RPC calls and uses the HTTP2 standard which makes it potentially more routable in complex network environments than raw sockets (and is apparently increasingly being used in microservice web architectures). LabVIEW support could be tricky for gRPC, but may not be a concern we care about.

There may also be projects other than gRPC that might be better!

It still probably makes sense to use ZMQ for communication that requires speed (like serialising dataframes in lyse for sending to analysis subprocesses) and probably ZProcess. My initial thoughts are that, if we decide to adopt a 3rd party RPC project, anything that is a low level private RPC API within a component could stay with ZMQ but public RPC between labscript-suite components would use the new RPC library.

Basically I think now is a good time to discuss bigger picture RPC changes before we do any more work on the ZMQ RPC. So I'm opening discussion to see if anyone has strong feelings either way and to suggest we do a search to see if how the 3rd party RPC library landscape has changed in the last 8 years.