# development


02/22/2019, 5:45 PM
@average-vr-56795 brought up the potential benefit of decoupling process management from rpc in another chat and also mentioned that we could consider using another rpc system besides nailgun, and it kinda blew my mind because i totally didn't realize that coupling process management with this specific rpc protocol was exactly what nailgun was doing (because i have not written that much software in my life) and it seemed like an interesting long-term thought process. i also then thought that "well, we have
executing processes, and that uses grpc i think, and wouldn't it be neat if we could use that directly or indirectly as the pantsd thin client itself?" -- as in, (hand waving) move most of the logic that is done in
and just send over the arguments? i personally think since we already have defined an extension of nailgun which we support on both the front and back end, it seems like it might not be an awful protocol to continue to use (i personally found it not too hard to extend and formalize in, although @average-vr-56795 reports that the canonical implementation (
and the
client) is often flaky. afaik
just gets all of the process output at once instead of streaming like e.g. nailgun supports, so i'd think we would not use the bazel remote execution api for executing pants itself anyway, and it seems like it would be an unnecessary earth-scorching to drop the nailgun protocol for this use unless there's an off-the-shelf alternative. it's also extremely possible (working to disprove this) that native-image might actually approach nailgun performance enough locally for us to just drop persistent process management with nailgun entirely, which would be a ridiculous amount of code we could delete if native-image ends up very reliably building jvm code. we would still want some support for persistent processes when we get to things like lsp/bsp servers (discussed in