morgan:
> > Case in point: HttpClient throws an HttpException in the event of a 401.
> > While this is probably perfectly reasonable behaviour for Slide, it's not
> > good for lots of other applications. First of all, a server returning a 401
> > is a normal condition, not an error condition. Secondly, the web server
> > will return potentially useful Headers with a 401, which are only available
> > if the request is processed normally.
dirk:
> Aren't the headers available in the method ? If not, we should change that.
> Returning an error code or throwing an exception, it's just a matter of taste,
> you always have to do a test and with exceptions the compiler reminds you.
returning an error code? it's an HTTP *status* code. it doesn't indicate an excpetion condition in the httpclient. if an application that uses httpclient wants to throw an exception when receiving an unfavorable HTTP *status* code, that is it's choice.
-doug
-----Original Message-----
From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 27, 2001 4:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [httpclient] Planning proposal
<snip>
> From: "Vincent Massol" <[EMAIL PROTECTED]>
> > That's something I had not understood : that client users where using the
> > httpclient API. I had thought it was only Slide itself internally. I agree
> > that in this case we have a problem. Hum ... I guess the only possible
> > issues is for Slide to wait until commons-httpclient is released and
> > provides some nice features it has a need for. That would justify the
> need.
> > The other option would be to remove everything that has been done in
> > commons-httpclient that is not backward compatible with Slide. However, as
> > you say that would involve a lot of work and I am not sure we'll have
> > everyone's committment on that. Also, there are bugs (like the multiple
> > headers one) that mandates a new client interface for httpclient. However
> it
> > is always possible to provide a default implementation that is backward
> > compatible (like HttpMethod.getHeaders which returns only the first
> > headers).
> Morgan Delagrange wrote:
> I'm hoping that Rod will submit patches to Slide to get it working correctly
> with his refactoring. That seems the logical course, since he's most
> familiar with the problems in HttpClient and how he tried to fix them. Or
> perhaps someone from Slide would volunteer to work with him. If not, then
> we do have a problem. As for any HttpClient classes that you've exposed
> externally in the Slide API, that's also a problem, depending on the extent
> to which you've exposed those classes, and how the users are utilizing them.
> This must have already been an issue for them, because of the inital
> repackaging.
> I can only assume that Rod felt refactoring was necessary in order to
> achieve a maintainable interface, so this sounds like an initial growing
> pain followed by a brighter upgrade path.
HttpClient is a connection to a server that executes HttpMethods. Slide just
adds WebdavMethods so everything is exposed.
There is a wrapper class that you can use to reduce the code needed to do simple
things but for more control you use the Method you need.
I myself support code that was written in slide 1.0.6 (before there was that
wrapper class) and it still works with the latest version.
The initial repackaging was no a real big issue, there is dummy slide GetMethod
class that extends the common GetMethod to provide backward compatibility.
And even then, changing an import statement is simpler then changing the way
credentials are managed or replacing functions all over the place.
Maybe Rod can give some reasons why things needed to change, what extra features
are possible with the new one, or wich bugs couldn't be resolved with the old
one.
<snip>
> > > For slide it is simple, we have a stable version and we have a lot of
> > > users.
> > > If you want to keep us as your customers then you need to provide us
> > > with support.
> > > Support the original HttpClient interface and provide a smooth upgrade
> > > path.
> > >
> >
> > I agree with this. Let's try to convince the others :)
>
> I think there may be problems in the original behaviour that will be
> difficult to maintain.
>
> Case in point: HttpClient throws an HttpException in the event of a 401.
> While this is probably perfectly reasonable behaviour for Slide, it's not
> good for lots of other applications. First of all, a server returning a 401
> is a normal condition, not an error condition. Secondly, the web server
> will return potentially useful Headers with a 401, which are only available
> if the request is processed normally.
Aren't the headers available in the method ? If not, we should change that.
Returning an error code or throwing an exception, it's just a matter of taste,
you always have to do a test and with exceptions the compiler reminds you.
> This is one of a few problems that I've encountered with the main branch,
> which is the branch that Latka currently uses. If we want to release a
> flexible client, I think there will be growing pains. (There certainly have
> been so far.)
Please submit bug reports to the slide list as well, we are using that version
also and every problem you report is one less we have to find for ourselves.
> > Let's try to correct our mistakes and work happily together.
> > -Vincent
>
> I'd like us to move forward as well.
> - Morgan
Same here
- Dirk
