commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [HttpClient] HttpURLConnection wrapper
Date Wed, 24 Jul 2002 08:59:49 GMT
Hi Jeff,

> -----Original Message-----
> From: jsdever [mailto:jsdever] On Behalf Of Jeff Dever
> Sent: 24 July 2002 04:33
> To: Jakarta Commons Developers List
> Subject: Re: [HttpClient] HttpURLConnection wrapper
> 
> Hey Vincent,
> 
> Its certainly sounds like a reasonable way to preserve your existing
> interface
> while changing the back end.  And because it is a standard java
interface,

Unfortunately it is not, which makes the work more difficult ... :-( I
wonder when Sun will learn to write clean code in the JDK ... It makes
it difficult to extend, difficult to test, etc.

> it
> also seems reasonable to have that as part of the HttpClient offering.
I
> don't
> think that HttpMethod maps very well onto HttpConnection, but much of
it
> looks
> workable.
> 

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.

> My biggest reservation is that HttpClient has too many public
interfaces
> already, and severaldifferent paradigms of use.  We are just starting
to
> address
> the mulititude of interfaces (particularly HttpClient/HttpMultiClient)
and
> am
> hesitent in adding one more.
> 
> We are working on a 2.0 release right now which is top priority.
There
> have
> been so many changes between the 2.0 alpha way back in October and the
> current
> code base, that we need to minimize what goes in at this point.
> 
> 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).

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).

It it completely non intrusive to any existing code of HttpClient so I
don't see any real reason not to include it for 2.0 but that's
HttpClient's committer call.

That said, I guess I can keep it in Cactus util/ package, but I don't
believe it belongs there and I'm sure there are others who also need it.

Anyway, it's your choice.

Thanks
-Vincent

> -jsd
> 
> 
> 
> Xiaowei Jiang wrote:
> 
> > +1, That is a great idea!
> >
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.com]
> > Sent: Tuesday, July 23, 2002 3:20 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [HttpClient] HttpURLConnection wrapper
> >
> > Hi,
> >
> > I am moving Jakarta Cactus from using the JDK HttpURLConnection to
> > Commons HttpClient. However, I have some public interface that
return
> > HttpURLConnection and I cannot break that contract with Cactus
users.
> >
> > I propose to write a HttpURLConnection wrapper for HttpMethod (I
have
> > actually already written it but I am currently testing it on Cactus
and
> > will make a proper donation once I am sure it works - i.e all the
Cactus
> > tests pass as before ... ).
> >
> > I attach a preview of it for those interested.
> >
> > What do you think of including it in HttpClient distribution ?
> >
> > Thanks
> > -Vincent
> >
> > --
> > To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message