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.
Refactor to introduce client/server separation, including a typed
client API and a HTTP REST server implementation.
Refactor the terminal to be an API consumer.
Notable changes:
* OS X support
* Pure Go readline library
* Fixes issues debugged cgo enabled programs
* Substantial refactoring / code cleanup
Fixes#3#29#70
First of a few refactors to allow multiple clients / frontends for
Delve. Current implementation now uses a cli client, but conceivably we
could have an http or socket based client as well.
