hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: HttpCore NIO questions
Date Sun, 17 Sep 2006 20:07:54 GMT
Hi Oleg,

>>We could start with an HttpConn module. The decision whether we'll
>>release it independently or only as part of HttpClient is still
>>pending, after all. See also below.
> This is exactly what I see as a proper place for this kind of code

We have to bear in mind that HttpCore is supposed to be useable without
any other module. Moving default implementations for connections out
of the core seems to clash with this goal.

>>I am considering to officially declare HttpAsync defunct and pulling it
>>from the website. [...]
> I disagree rather strongly. It is true that HttpAsync still lacks a
> clearly defined scope and it represents an experimental branch in
> HttpComponents development, but I certainly see HttpAsync as a very
> valuable and important development effort. I personally see it as a set
> of extensions to HttpCore and HttpClient targeted at those use cases
> where scalability and efficient thread management is a more important
> that raw performance delivered by blocking I/O. I also think it should
> be making an extensive use of NIO extensions to achieve those goals.
> I personally am very interested in working on an async equivalent of the
> HttpService class capable of handling a large number of high latency
> connections with a fixed number of threads. 
> So, overall, it is very premature to declare HttpAsync as defunct. It
> may take a lower priority to delivering the first ALPHA of HttpClient
> 4.0, but it by no means a less interesting project.

Well maybe not defunct, but at least suspended. The point is that most
of the time I wanted to invest into implementing the pending changes to
HttpAsync (client side) has gone into a new build process and redesigning
connection handling in HttpCore, and now we're at a point where the
HttpCore API is not even sufficient to implement HttpAsync/CS anymore.
I'm tired of being delayed again and again. Every time I want to pick up
on HttpAsync/CS development, I need to spend an hour with the code to even
understand where I left it the last time. I'd rather call it quits until
such time that the required base APIs are stabilized and I can concentrate
on delivering HttpAsync/CS in one go. It's also fairer to the potential
users to tell them that they have to wait for months, if not a year or so,
until there's something to consider for use. Last December, I wrote that I
hoped to contribute an initial implementation over the course of this year:
I am not much closer to this goal than at that time, and I don't see
that changing for the coming months (6? 9? more?). Giving not only HttpCore
but also HttpClient and related components a higher priority means that
there will be none of my time left for the client part of HttpAsync that
I wanted to contribute. And not giving them a higher priority would mean
that I have to shoot at a moving target, spending considerable time to
compensate for code changes in the base APIs, or to implement provisional
versions of stuff that will most likely have to be rewritten completely
later on. I consider my time too precious for that. It's better invested
into HttpCore & Co. Which means that HttpAsync/CS will lie dead until
further notice.


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

View raw message