Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sberlin@gmail.com designates
 64.233.184.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OBxnHmkclRcnFTNAI5fXaQbEYVoll/gAJ5BfOwSlOmdxGiJBBPzAHikjnC5FkZYwn4F78fLXnvv4Jv7akz147B8EMhiEHkBlSKvU9jBEXAf5UR/n4TxGzNfvdK1mziBAxvlNgLkdOqJxzDb74eeiE8AsR1tzRfVhBQmwn/CkvDU=
Message-ID: <19196d860803260821v15eca860pdc0b75bea59abf05@mail.gmail.com>
Date: Wed, 26 Mar 2008 11:21:06 -0400
From: "Sam Berlin" <sberlin@gmail.com>
To: "HttpComponents Project" <dev@hc.apache.org>
Subject: Re: NIO based connection manager impl / async HttpClient
In-Reply-To: <1206538730.5818.3.camel@ubuntu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1206538730.5818.3.camel@ubuntu>

> (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.)

> (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.

Sam

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