Client Ergonomics

[reem]

Looking at the benchmark, comparing hyper to curl does not look good for hyper. I'm convinced that this is probably relatively easily fixed with a few convenience methods, but they go a long way and should either be implemented or the API should be defined explicitly with downstream libraries implementing those methods in mind.

[seanmonstar]

What convenience methods do you mean?

Also, I'd forgotten to update the benchmarks since adding the use of BufferedWriter and BufferedReader, which dropped hyper's ns/iter to ~170000. I'll update the readme.

[seanmonstar]

Hrm, I did reach that number a few days ago, but current benchmarks are back around ~230k...

[seanmonstar]

Still, what is meant by "client ergonomics" in this issue?

[reem]

I personally prefer the method chaining API offered by curl, considering that most requests are made and sent all at once and not modified by a large number of different functions like a server request.

I have a rough sketch of this API in one of my branches, I'll probably make a PR later today.

[seanmonstar]

My thoughts are that the httplibrary should provide the basic blocks,
having an efficient api using Writers. Then, I considered the main module
to have a nice request builder interface, for doing simple requests. But
the building blocks are still there for people to extend on.
On Sep 10, 2014 11:28 AM, "Jonathan Reem" notifications@github.com wrote:

I personally prefer the method chaining API offered by curl, considering
that most requests are made and sent all at once and not modified by a
large number of different functions like a server request.

I have a rough sketch of this API in one of my branches, I'll probably
make a PR later today.

—
Reply to this email directly or view it on GitHub
#11 (comment).

[reem]

Hmm. I sort of agree with this, that means we just leave room for a "smoother" library on top of this. Closing.

[seanmonstar]

I've considered possibly having a RequestBuilder pattern for the client, exposed from hyper::request()... but it also seems like something a higher level library could do. With the raw Request/Response blocks exposed, different APIs can be built, regardless.