Folks,

I have completed the first cut at the non-blocking NIO HTTP transport.
Both client and server side implementations are (more or less) feature
complete at this point. 

These are the sample apps demonstrating the new API in action

Non blocking HTTP server:
http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/module-nio/src/examples/org/apache/http/nio/examples/NHttpServer.java

Non blocking HTTP client:
http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/module-nio/src/examples/org/apache/http/nio/examples/NHttpClient.java

Before I go on hacking I would love to get some initial feedback. Please
let me know what you think

Next two big things on my to-do list are
* InputStream / OutputStream wrappers
* Default IO reactor refinements. I would like to add an option enabling
the IO reactor to run multiple I/O event dispatch threads (mainly for
multiprocessor systems)

Cheers

Oleg 


On Thu, 2006-10-26 at 10:24 +0200, Oleg Kalnichevski wrote:
> Folks,
> 
> I have largely finished the server side components of the event-driven
> HTTP transport and am in the process of putting the final touches on the
> client side components. The code is still a little rough around the
> edges but so far has been holding up quite well for me. Content chunk
> coding, header folding, content footers, proper protocol version
> handling, expect-continue handshake are supported. The HTTP transport
> should be able to handle content of arbitrary length with (almost)
> content memory footprint. There is no intermediate buffering involved at
> all in those cases where no content coding is required. Request /
> response content gets directly read from / written to the underlying
> socket channel. 
> 
> Here is a sample of a simple HTTP server demonstrating the new API in
> action
> 
> http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/module-nio/src/examples/org/apache/http/nio/examples/NHttpServer.java
> 
> My next steps will be to complete the client side components and to
> implement a compatibility layer on top of the even driven API for those
> applications that rely on InputStream / OutputStream interface to
> consume / produce content. Some early feedback would be _hugely_
> appreciated, though.
> 
> Cheers
> 
> Oleg
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to