On Sun, 2006-09-17 at 22:07 +0200, Roland Weber wrote: > 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.
The default implementations should stay in HttpCore, but they should be (at least in my opinion) only implement a simple method allowing the connection to be bound to an open socket. Code aspects that define how exactly that socket gets initialized (directly or via a proxy) belongs to HttpConn in my opinion. This is just a proposal. If you object to such a change it will not happen. > > >>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. > HttpAsync has not seen a single official release. There is no need to make any declarations. Client side connection management is the last hurdle that need to be removed before HttpCore API is ready to be stabilized. The simpler and the more generic it is going to be the better it is for all the modules that sit on top of it. I have always been trying to say that controlled code duplication in HttpAsync is a lesser evil because it can shield HttpAsync from API instability in HttpCore. Go ahead and roll out an HttpAsync specific extension of HttpClientConnection interface and its default implementation. Once we start seeing code commonalities in HttpAsync, HttpConn and HttpClient, we can always push common aspects downstream to HttpCore. It is easier to observe commonalities in code then to predict them. Oleg > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
