7c8fd02685
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. |
||
|---|---|---|
| .. | ||
| api | ||
| debugger | ||
| rpc | ||
| test | ||
| client.go | ||
| config.go | ||
| server.go | ||