Awesome stuff, Yehuda! I look forward to this making its way into a  
distribution.

On 18/07/2011, at 4:44 PM, Yehuda Katz wrote:
> 	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  f reactor

Does this also work with SSL?

I recall seeing tweets from you questioning why reading from an SSL  
socket
might be affected by whether the socket is currently writable - I  
assume you
worked out that it's due to handshaking (which can be re-initiated at  ny point
during an SSL connection). Even though the application layer is in a  
mode
where it expects only to read, the handshake may require writing, and  ence
can block on write if the socket is currently stalled.

> 	Make the body parsers (regular body and chunked encoding)  eparate objects that can support either blocking read or non- 
> blocking read.

Heh. Now all we need is a revision of the Rack API to allow reading  
chunked
bodies in a piecemeal fashion. They can already be sent, because the
response body may be enumerable - though that's still not reactor- 
friendly.

I use async_sinatra which hacks Thin to make the EventMachine reactor
work correctly - see http://github.com/raggi's projects.

Integration to support websockets is also high on the list of wants.  
You should
ask on <mailto:socket_io / googlegroups.com> how best to do that, since  any
of the interested parties hang out there.

> 	Improving the tests to test non-blocking read across all kinds of  
> requests, and add tests for decompression

I'd be interested in how you test non-blocking for SSL connections,  
seeing as
you need a custom SSL server which triggers renewed handshakes to do it
properly...?

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design
Skype: cjheath, Ph: (+61/0)401-533-540