On Sun, 6 May 2001, Park, Sung-Gu wrote:
>
> ----- 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. ;-)
I agree that inputing credentials before URL is odd, and it's really only
that way coincidentally once we ripped out the URL-based
constructors. How about this instead?
HttpClient()
startSession(URL url)
startSession(URL url, Credentials creds)
startSession(String hostname, String port)
startSession(String hostname, String port, Credentials creds)
>
> > > > > > > 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.
> >
> >
>
>
