--20cf307abd6d692b2e04a8756452 Content-Type: text/plain; charset=ISO-8859-1 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 > > --20cf307abd6d692b2e04a8756452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br clear="all">Yehuda Katz<br>Chief Technologist | Strobe<br>(ph) 718.877.1325<br> <br><br><div class="gmail_quote">On Mon, Jul 18, 2011 at 7:05 PM, Tanaka Akira <span dir="ltr"><akr / fsij.org></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 2011/7/18 Yehuda Katz <wycats / gmail.com>:<br> <div class="im">> I gave a talk at Ruby Kaigi about my work on Net::HTTP<br> > (<a href="https://github.com/wycats/net-http" target="_blank">https://github.com/wycats/net-http</a>) and Net::Reactor<br> > (<a href="https://github.com/wycats/net2-reactor" target="_blank">https://github.com/wycats/net2-reactor</a>), and asked that they be considered<br> > for inclusion into Ruby. Several people suggested that I send an emailo<br> > this list, so here I am! Since Ruby 1.9.3 is almost finished, I would<br> > propose to include my improvements to Net::HTTP in Ruby 1.9.4.<br> > When I started working on improving Net::HTTP, my main goal was to make it<br> > possible to make a request without reading the response at the same time.<br> > Since then, I have also worked on a number of other improvements.<br> <br> </div>Making HTTP similar to IO is interesting idea.<br> However jumbo patch is hard to incorporate.<br></blockquote><div><br></div><div>I'm not sure how to do this work with a series of smaller patches.onsidered it, but it was very difficult. There is no current maintainerf Net::HTTP - I would be willing to maintain it if my patch was accepted.erhaps this makes a large change more acceptable?</div> <div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">> All kinds of requests can support GZip and Inflate<br> > It is possible to read_nonblock from Net::HTTP response, even if the<br> > response has Transfer-Encoding: Chunked, keepalive or compression. This<br> > makes it possible to use Net::HTTP in reactor libraries, instead of writing<br> > whole new HTTP libraries for each kind of reactor<br> <br> </div>Event-driven systems should consider all blocking operations read/write/connect.<br> But your proposal consider only for read.<br> I think write operation may block if HTTP POST has large data.<br></blockquote><div><br></div><div>Yes, that is true. I am planning to add evented paths for all three operations, but the response was the biggest concern for me.</div> <div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > My intent was to retain full backwards compatibility across the API with one<br> > small change:<br> ><br> > When using the block form of the request instance method ( http.request(...)<br> > { ... } ), the behavior remains the same: the body is read synchronously.<br> > However, when a block is not passed, the body is not read until it is<br> > requested. This makes read_nonblock possible. This means that when a block<br> > is not passed, it is up to the consumer of the API to close the response<br> > when they are done with it.<br> <br> </div>Why don't you create a new method for the incompatible behavior?<br></blockquote><div><br></div><div>Good idea. I have started to write a new raw_request method that incorporates the new behavior and makes all implicit behavior optional.</div> <div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> --<br> <font color="#888888">Tanaka Akira<br> <br> </font></blockquote></div><br> --20cf307abd6d692b2e04a8756452--