Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: NIO based connection manager impl / async HttpClient
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
In-Reply-To: <19196d860803260821v15eca860pdc0b75bea59abf05@mail.gmail.com>
References: <1206538730.5818.3.camel@ubuntu>
	 <19196d860803260821v15eca860pdc0b75bea59abf05@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 26 Mar 2008 20:16:54 +0100
Message-Id: <1206559014.5750.14.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Wed, 2008-03-26 at 11:21 -0400, Sam Berlin wrote:
> > (1) First off, are there any objections to developing an NIO connection
> > manager within HC?
> 
> Not from me -- I think it definitely falls within the scope of the
> project, given that NIO components already exist and seem to be used
> by a good number of people.
> 
> > (2) If there are no objection to hosting this code here, shall NIO based
> > client-side components be developed as a project distinct from
> > traditional HttpClient with a separate release cycle, probably even
> > starting with the release version 1.0, or shall we develop it as a
> > module of HttpClient sharing the same release cycle?
> 
> I vote for a distinct project with its own release cycle -- of course,
> I have no clue the amount of work involved with that.  My rationale
> for wanting a separate cycle is that the httpcore-nio component is
> much more tightly tied with httpcore than httpclient-nio would
> presumably be tied with httpclient.  The whole httpclient stack is
> very blocking-based, and very little could could be reused.  In my
> head, the two are completely different entities.  (Of course, if
> ultimately we find there is could that can be reused, and that code
> moves into a common httpclient module that's shared by httpclient-bio
> and httpclient-nio, then maybe it does make sense to share a release
> cycle.)
> 

Hi Sam

I really hope we manage to re-use at least some of the low level
primitives from HttpConn. Anyway, I suggest we start hacking quietly in
the sandbox and see how things shape up. Depending on how well (or
badly) we fare, we can either pull the plug on the whole thing, promote
it to a full-fledged project or fold it into HttpClient.  


> > (3) Anyone interested in getting involved in the early stages of
> > development and helping me define the API and the component architecture
> > for the NIO connection manager?
> 
> I'm game, especially as I'll be working on utilizing httpcore-nio for
> LimeWire's downloads around the same time.  (I'm sidetracked right now
> on preparing for a new release, but that should only last a few
> weeks.)  Step 1, I think, would be to go through the blocking
> connection managers and define what it is they're useful for & what
> they do, and tweak the ideas around a bit to work in a non-blocking
> context.
> 

Cool. Sounds encouraging!

Cheers

Oleg 

> Sam
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org