commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <>
Subject RE: [HttpClient] HttpURLConnection wrapper
Date Wed, 24 Jul 2002 14:26:04 GMT

> What are the problems you see ? It is not my intention to map outgoing
> calls to the remote server but rather to map the HTTP response with it
> as shown in the attachment in my previous email.
I see that mapping responses only meets your needs, but the presence of such
a compatibility layer inside HttpClient would imply more functionality.  I
would expect that others would request more and more functionality out of
the HttpURLConnection layer, which would become harder and harder to satisfy
because the HttpClient usage model(s) are quite different from
HttpConnection.  It could get messy fast and unrealistic to implement

> > 
> > But 2.1 is a different story, and would likely get quite a bit of
> support.
> > 
> I don't view it as a new interface that we promote as such but rather as
> a helper factory class to create a HttpURLConnection out of a
> HttpMethod. I wouldn't put it in the main package but create a new
> package (pick the name : compatibility, contrib, util, etc).
Thats a pretty reasonable view on the proposed functionality.  More
minimalistic than what I was expecting (which is good!)

> In addition, this proposal is not new : I actually proposed it about 6
> months ago and if I recall correctly it was well received (I did not
> find the time to do it at that time).
I don't mean to sound negative on this, but I am just about to propose a 2.0
release plan and this enhancement request comes pretty late.  It's been 10
months since 2.0 Alpha1 (which is really bad) But there have been positive
comments by active contributors so we should consider this for 2.0.  If you
are willing to provide this functionality (complete with unit tests) in a
reasonable timeframe (say 2 weeks) then I'll add it to the proposed 2.0
Milestone 2 content list.  

BTW: I'm not the release manager here, but I am trying to fill the gap.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message