----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 1:49 AM
Subject: Re: constructors and startSession in HttpClient
>
>
> On Thu, 3 May 2001, Morgan Delagrange wrote:
>
> >
> >
> > On Thu, 3 May 2001, Park, Sung-Gu wrote:
> >
> > > > > > I'm thinking about reworking the way the constructors and
startSession
> > > > > > methods work in the HttpClient class. I think it's a little
confusing
> > > > > > right now. Currently HttpClient has three constructors:
> > > > > >
> > > > > > HttpClient()
> > > > > > HttpClient(URL url)
> > > > > > HttpClient(URL url, String user, String password)
> > > > > >
> > > > > > and three startSession methods:
> > > > > >
> > > > > > startSession()
> > > > > > startSession(URL url)
> > > > > > startSession(String hostname, String port)
> > > > > >
> > > > > > I think that this will introduct too much confusion. For
example,
> > > what
> > > > > > happens when I do the following?
> > > > > >
> > > > > > HttpClient client = new HttpClient(new
URL("http://java.sun.com";));
> > > > > > client.startSession();
> > > > > >
> > > > > > You may think that you've opened a session on "java.sun.com:80",
but
> > > what
> > > > > > you've actually done is opened a session for "localhost:80".
Even if
> > > we
> > > > > > noted this in the javadocs, I still think programmers would
screw it
> > > > > > up. Also worthy of note is that the above code instantiates the
State
> > > > > > object twice before it is even used. :(
> > > > >
> > > > > > I think a more clear API would be only two constructors and only
two
> > > start
> > > > > > session methods:
> > > > > >
> > > > > > HttpClient()
> > > > > > HttpClient(String user, String password)
It looks wiered. Please think of the way to connect a server.
When you connect to, what is it needed for the server?
I assume that's the hostname and port.
If authorization is requested by the server, then we need to give
the values of the username and passowrd. That's the order.
And we have to think of the requiremets for the constructor.
What I mean is that if we don't have server information as a constructor,
We don't need to have one with the userinfo constructor.
Hmm.. I recommend us to have constructors of server information
and user information for easy, not just preferring. ;-)
> > > > > > startSession(URL url)
> > > > > > startSession(String hostname, String port)
> > > > > >
> > > > > > This will have the added advantage of not having to instantiate
the
> > > State
> > > > > > objects multiple times for a single request.
> > > > >
> > > > > Ok, you have a case ;)
> > > > > I don't like the alternate constructors either. Originally, there
was
> > > only
> > > > > the default constructor, which was simpler IMO.
> > > > > I would deprecate instead of removing right away.
> > > > >
> > > > > > Also, the javadocs should note that using startSession(URL) only
> > > populates
> > > > > > the hostname and port, not the path of any subsequent
HttpMethods.
> > > > >
> > > > > Good idea.
> > > > >
> > > > > Remy
> > > >
> > > > Great! If there are no objections, I'll deprecate those methods and
> > > > update the JavaDocs today.
> > >
> > > I'd like recommend you not to use java.net.URL class.
> > > It's confused develpers to use it related to the compatibility.
> > > The calss in JDK 1.x doesn't have the userinfo part.
> > > However, The class in JDK 2.x have the userinfo part.
> > > Perhaps, developers might expect to set credentails for
> > > HttpClient by using the class.
> > > So I recommend us to have the arguments of host, port and
> > > possibly path as String.
> > > (It's just like the user and password for credentials... )
> > > Actually, the class is just for parsing... not URLConnection. here...
> > >
> > > What do you guys think of my opinion? ;-)
> > >
> >
> > I take your point, but can't we simply note this in the JavaDocs? It
> > seems like many applications that use HttpClient will be working from
> > URLs, and it would be nice to support them in the interface with the
> > appropriate warnings.
> >
>
> I would suggest that HttpClient should, at a minimum, *support* the use of
> URLs as constructor arguments. Getting the syntax of a URL correct is
> something lots of Java developers do with string manipulations, and it
> causes untold numbers of bugs. I'm going to be going through the code for
> Tomcat and Struts to clean up the cases where I am currently doing this,
I think it's desirable. ;-)
> to avoid future problems with funky things like IPv6 literal host
> addresses (which use ":" instead of "." to separate the components of the
> IP address.
Yes, I *thought* for the first time, that looks really funky.
As you mentioned, InetAddress using in java.net.URL will make problems
future.
I agree with you. ;-) Actually we have to be hesitated to use the URL
class.
Fortunately, there is a solution for the future.
I believe that the solution's using URI with escaping. ;-)
> Take string arguments if you want in alternative constructors -- just
> don't deprecate the URL based ones, please :-).
>
> > - Morgan
> >
> >
> >
>
> Craig
>
> PS: With regards to JDK 1.1 versus 1.2 -- is that really an
> issue? HttpClient is of course free to decide what the minimum platform
> it wants is, but I note that many/most of the Commons packages are
> starting with JDK 1.2 as a minimum platform.
>
>
