Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of dan.in.a.bottle@gmail.com
 designates 66.249.82.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=pXqL9AgMoDVEQZIy7aU0k75VsgTYdHwULmicwz3mwrsqpR2oWJwlfRb/YrSokmrUEViMky+WfKMoCdeGC0mOK2CjR48EII666ItdMG0sycufGIfxXCAGXC9tYGduJa0DupEErag1nBxPYI6ZXX17/MRmJ+tObIJF7RD4/pWWd20=
Message-ID: <3fb8d2f00706100510n4b40e7c8kc8fa8633c45df969@mail.gmail.com>
Date: Sun, 10 Jun 2007 14:10:20 +0200
From: "Daniel Mueller" <dan@digitalstrider.com>
Sender: dan.in.a.bottle@gmail.com
To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Subject: Re: current state of httpclient 4.0
In-Reply-To: <1181474170.28486.28.camel@okhost>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_48947_4294560.1181477420669"
References: <3fb8d2f00706100344g58d9f093i8acf60978e2eebde@mail.gmail.com>
	 <1181474170.28486.28.camel@okhost>

------=_Part_48947_4294560.1181477420669
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> >  And since my main interest lies in the nio part
> > of the httpcore, what needs to be done to have this part working with
> the
> > httpclient (if there's anything which is not working, not sure about
> that)?
> > Some pointers would be great, so I can speed up my understanding of the
> > code.
> >
>
> This used to be and still is a major point of contention. I believe NIO
> makes very little sense for 'pure' HTTP servers and clients. To date NIO
> has always tended to be significantly slower than classic I/O as long as
> the number of I/O worker threads was below several thousands. I still do
> not see a valid use case where a pure HTTP client may need more than
> just a handful of I/O threads (a few hundred at most). That basically
> eliminates all advantages of NIO for HttpClient.


Having said all that, I am very, very, very open to helping people build
> client side components based on HttpCore NIO to be used in some HTTP
> proxy or gateway services.
>

I have a quite limited knowledge of NIO and IO in general as a matter of
fact. Not much beside mostly theoretical stuff and these things often don't
apply one to one in the field. Having said that my use case is the
following:
I want to build an access layer to the amazon S3 service. The S3 service has
a SOAP and a REST API and I'm currently opting for the REST variant. This
access layer will be used as one of the back ends of a processing pipeline
inside a server. The rest of the server is built in SEDA style with event
driven/asynchronous interfaces between the stages. That's why I need my
access layer to be event driven/asynchronous. The logical step was then to
think about implementing the access layer also in a asynchronous manner
which is where NIO came into view because it encourages that kind of design.
While investigating S3, REST, NIO and asynchronous (http) clients I stumbled
accross several interesting things and one of them is the restlet API[1]. It
looks as if it would solve a good portion of my demands for an asynchronous
handling of resources, but has no asynchronous client implementation as of
today. The one they do have is built on httpclient 3.x. While following that
trail I ended up with your still alpha version of httpcomponents and decided
to have a look.
If you have a look at my use case and then think a bit further along that
line of thought you end up with something that almost behaves like a gateway
but uses webservices (REST or SOAP) as the backend. WS* and REST is all the
rage today. While it certainly does not solve all the advertised problems,
it does solve a couple. And building your servers in a non-blocking fashion
is also gaining momentum (I have no good pointers for this one, it's simply
a gut feeling). And the last link in the chain is the call to backend
systems of any sort (web services, databases, file system, whatever). So
maybe from this point of view, NIO makes sense after all.

Currently most of these ideas are still being formulated and I'm simply
looking for ways to achieve what I have in mind. I've spotted your view on
NIO http clients already somewhere else in the list-archives and would
certainly be very interested if you could elaborate a bit. Those plans I
have aren't set in stone and I want a solution which solves my problem,
nothing more.

But if the architecture makes any sense at all, I do have to have the
components to achieve it. And I will help to get things rolling where I can
in the httpcomponents project.

Thanks and cheers
Daniel

[1] http://www.restlet.org/

------=_Part_48947_4294560.1181477420669--