6 ms·

It took me a while to figure out whether this is an HTTP client library or a server library. Turns out it is the former. Nice! I like that it's in-process. I wi

It took me a while to figure out whether this is an HTTP client library or a server library. Turns out it is the former. Nice! I like that it's in-process. I wish more Elixir libraries would default to such a design. (EDIT: I had accidentally written "latter" instead of "former" above, causing a bunch of people to correct me, thanks for that)

thibaut_barrere 8y ago
It's a "new HTTP client" (tweet from one of the authors -> https://twitter.com/whatyouhide/status/1100082898986774528 https://twitter.com/whatyouhide/status/1100082898986774528).
hartator 8y ago
The example is confusing, but it's actually an HTTP client.
derefr 8y ago
I've noticed that the distinction between server and client is much less apparent in HTTP2 libraries than it was in HTTP1 libraries. It doesn't seem like Mint follows this philosophy, but many HTTP2 libraries (even ones that also support HTTP1) are both server and client libraries. Presumably this is because HTTP2 is sort of two protocol layers stuck together—a session layer and an application layer—and at the session layer, HTTP2 just has identical "peers" rather than any concept of client/server. (Theoretically either side of an HTTP2 connection could open a session to the other side and send a message! It's just the semantics of the HTTP-mimicking application layer that stop this. If you read the RFC, all the session stuff—frames et al—are specified in terms of "peers", and it's only when the spec starts talking about HTTP request-response that we see "clients" and "servers" mentioned.) Since implementing the session layer is most of the work of implementing an HTTP2 client/server, and the session layer is just about "peers", once you've implemented it for a client (or server), you can reuse it to implement a server (or client) mostly "for free."
msie 8y ago
So, it's the former (client library).
davidw 8y ago
In the Erlang world... it's always yet another client.

thibaut_barrere 8y ago

It's a "new HTTP client" (tweet from one of the authors -> https://twitter.com/whatyouhide/status/1100082898986774528 https://twitter.com/whatyouhide/status/1100082898986774528).

hartator 8y ago

The example is confusing, but it's actually an HTTP client.

derefr 8y ago

I've noticed that the distinction between server and client is much less apparent in HTTP2 libraries than it was in HTTP1 libraries. It doesn't seem like Mint follows this philosophy, but many HTTP2 libraries (even ones that also support HTTP1) are both server and client libraries. Presumably this is because HTTP2 is sort of two protocol layers stuck together—a session layer and an application layer—and at the session layer, HTTP2 just has identical "peers" rather than any concept of client/server. (Theoretically either side of an HTTP2 connection could open a session to the other side and send a message! It's just the semantics of the HTTP-mimicking application layer that stop this. If you read the RFC, all the session stuff—frames et al—are specified in terms of "peers", and it's only when the spec starts talking about HTTP request-response that we see "clients" and "servers" mentioned.) Since implementing the session layer is most of the work of implementing an HTTP2 client/server, and the session layer is just about "peers", once you've implemented it for a client (or server), you can reuse it to implement a server (or client) mostly "for free."

msie 8y ago

So, it's the former (client library).

davidw 8y ago

In the Erlang world... it's always yet another client.