> > > 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)
> > > 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? ;-)
Sung-Gu
