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: http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-dev/200512.mbox/[EMAIL PROTECTED] 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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
