Instead of maintaining two separate client / server implementations,
maintain only the more lightweight JSON-RPC service. The reasoning
behind the merging of the original HTTP service was ease of tooling, in
other words low barrier of entry for external clients (editor
integrations, etc...).
I believe the JSON-RPC solution still satisfies that constraint while
have the advantage of being a more lightweight solution. HTTP, while
highly supported in most modern languages, carries with it too many
features we would never take advantage of. The RPC architecture seems
a more natural approach.
The infrastructure set up during the initial HTTP service implementation
was leveraged in the JSON-RPC implementation, so if any of those
original authors are reading this commit message: thank you for that
work, it was not in vain even if though the original HTTP service is not
being removed.
7c8fd02685