hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: DO NOT REPLY [Bug 21754] - NullPointerException when releasing connection
Date Mon, 21 Jul 2003 09:57:54 GMT
> I understand this as a recent bugbear of yours :-) I am not asking for 
> no change, far from it. Instead, what I am asking is: what is the 
> supported 'user profile'? For example, will this profile support 
> 'component assemblers' as well as 'User-Agent users'? From my point of 
> view I see the HttpClient library as a grab-bag of components to stick 
> together, not a single entry point.

I also tend to see HttpClient as a toolkit, rather than an 'one size fits all' HTTP agent.
The problem is that HttpClient has still a long way to go before its API can be considered
flexible enough to serve a purpose of a generic HTTP toolkit. Besides, a significant group
of HttpClient users are pretty comfortable with HttpClient just being a simple HTTP agent,
and there's significant pressure from those users to simply leave things as they are. We have
been trying to walk a fine line between at times conflicting interests of various power groups
within HttpClient user base. So, it will take time before we get there without alienating
a sizeable number of existing users

> I have followed the discussion around the need to refactor the 
> internals of the HttpClient library for some time and I would certainly 
> agree that they need reworking. But what is the end goal? Is it "almost 
> a User-Agent (just add water)" ie the HttpClient class-to-be?

Ideally HttpClient should be both: a toolkit and a 'just add water' HTTP agent built on top
of it. 

>  The main reason I am coming to the HttpClient library is because 
> existing solutions such as the Sun one or innovation.ch have bugs or 
> aren't transparent enough. I already have a User-Agent which does 
> everything the HttpClient class does. I just need a way to plug in an 
> HTTP 1.1 provider which performs better and does not have the same 
> bugs/deficiencies as Sun/innovation.ch. If you wish I can itemize 
> exactly what is wrong with these libraries and tell you what I need.

I believe it would be time well spent, and your input will be highly appreciated. We will
not be able to incorporate your requirements right away, but we will certainly try to implement
those of them that are feasible within the existing architecture. Once 2.1 (or whatever number
we'll end up slapping on it) is out, we will embark on a complete API redesign and will try
to incorporate those ideas and suggestion that are currently not possible. 

Oleg (aka Evil Comrade Oleg)

View raw message