On Sun, 2006-09-17 at 18:24 +0200, Roland Weber wrote: > Hi Oleg, > I hate having the same class/interface names in different packages. > I remember trying to override an initialization method that was given > a Properties argument. I failed miserably, until I realized that it > wasn't java.util.Properties but a project specific Properties class. >
Same here. But right now for the lack of better ideas this is all I can think of. > > However, I understand you may want to use this interface in HttpAsync > > > 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 > > > To make matters even worse we have the following feature request to take > > care of: > > > > https://issues.apache.org/jira/browse/HTTPCLIENT-475 > > > > This is yet another reason why I think there is no way around having a > > HttpClient specific HTTP connection and connection management interfaces > > and another motivating factor for me to reduce the connection management > > code in HttpCore to an absolute minimum. > > > > SocketFactory in HttpCore is very likely to be my next victim. > > I am considering to officially declare HttpAsync defunct and pulling it > from the website. It was always caught between a rock and a hard place, > since it has to use HttpCore but also needs to provide functionality > for which (synchronous) APIs will only be discussed as part of HttpClient. > Now that we are even removing functionality from HttpCore, the work that > I would have to accomplish in order to make HttpAsync functional is > just piling up more and more. 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. Cheers, Oleg > And whatever is put into HttpAsync now > will need to be reconsidered once we're working on the corresponding > part of HttpClient or one of the other modules. I can't help thinking > that any time spent on HttpAsync at this stage is wasted. > > > > 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]
