Yehuda Katz
Chief Technologist | Strobe
(ph) 718.877.1325


On Mon, Jul 18, 2011 at 7:05 PM, Tanaka Akira <akr / fsij.org> wrote:

> 2011/7/18 Yehuda Katz <wycats / gmail.com>:
> > I gave a talk at Ruby Kaigi about my work on Net::HTTP
> > (https://github.com/wycats/net-http) and Net::Reactor
> > (https://github.com/wycats/net2-reactor), and asked that they be
> considered
> > for inclusion into Ruby. Several people suggested that I send an email to
> > this list, so here I am! Since Ruby 1.9.3 is almost finished, I would
> > propose to include my improvements to Net::HTTP in Ruby 1.9.4.
> > When I started working on improving Net::HTTP, my main goal was to make
> it
> > possible to make a request without reading the response at the same time.
> > Since then, I have also worked on a number of other improvements.
>
> Making HTTP similar to IO is interesting idea.
> However jumbo patch is hard to incorporate.
>

I'm not sure how to do this work with a series of smaller patches. I
considered it, but it was very difficult. There is no current maintainer of
Net::HTTP - I would be willing to maintain it if my patch was accepted.
Perhaps this makes a large change more acceptable?


> > All kinds of requests can support GZip and Inflate
> > It is possible to read_nonblock from Net::HTTP response, even if the
> > response has Transfer-Encoding: Chunked, keepalive or compression. This
> > makes it possible to use Net::HTTP in reactor libraries, instead of
> writing
> > whole new HTTP libraries for each kind of reactor
>
> Event-driven systems should consider all blocking operations
> read/write/connect.
> But your proposal consider only for read.
> I think write operation may block if HTTP POST has large data.
>

Yes, that is true. I am planning to add evented paths for all three
operations, but the response was the biggest concern for me.


>
> > My intent was to retain full backwards compatibility across the API with
> one
> > small change:
> >
> > When using the block form of the request instance method (
> http.request(...)
> > { ... } ), the behavior remains the same: the body is read synchronously.
> > However, when a block is not passed, the body is not read until it is
> > requested. This makes read_nonblock possible. This means that when a
> block
> > is not passed, it is up to the consumer of the API to close the response
> > when they are done with it.
>
> Why don't you create a new method for the incompatible behavior?
>

Good idea. I have started to write a new raw_request method that
incorporates the new behavior and makes all implicit behavior optional.


> --
> Tanaka Akira
>
>