4 ms·
The text interface primarily has simplicity on its side. The goal was to implement a set of commands with a small footprint. HTTP would have provided "too much"
by iamduo 10y ago
The text interface primarily has simplicity on its side. The goal was to implement a set of commands with a small footprint. HTTP would have provided "too much" for me to worry about in terms of designing the commands. However, HTTP2 was considered at one point, but it proved to be "too much" at the time.
From my own experience, the text commands are easier to test against, especially its boundaries (inputs to the server) which makes client development significantly easier.
- karmakaze 10y agoI can see how designing the command language can be simpler and cleaner in text than say XML. HTTP offers so much tooling, I might have gone with text over HTTP or JSON with a `command` entry. As for HTTP2, isn't that handled by the HTTP server/client implementations and is from the application code the same as HTTP?
- iamduo 10y agoI can definitely agree on the HTTP tooling! As for the HTTP2 portion, the server details would be abstracted out especially with HTTP2 support in Go 1.6. At the time I looked, HTTP2 clients for various languages were still popping up and stabilizing (I think they still are). I didn't want that to be a factor when I was developing clients outside of Go (for example PHP). In addition, an important goal was to develop extremely small clients, where I understood exactly what was going over the wire. If there are enough direct tooling benefits that HTTP2 can offer, it would be fun to experiment with it as an alternative interface. Funny enough, the first prototype name of the project was "httpq".