when we first started using httpclient, we didn't intend to do any development on it. however, as morgan, vincent, and others have discovered, there were many problems with it. a couple i can think of off the top of my head were mishandling of domains in the cookie code and no content-length header sent to the server on a post.
if httpclient is to be a commons component, the main focus should be a stable, reliable HTTP client. this might require changes to the interface. i agree, as does morgan, that api changes should be minimized. *but*, if changes are necessary to facilitate this, then we should bite the bullet before releasing a 1.0 version of the code.
-doug
-----Original Message-----
From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 27, 2001 3:45 PM
To: [EMAIL PROTECTED]; Vincent Massol
Subject: Re: [httpclient] Planning proposal
----- Original Message -----
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 3:00 PM
Subject: Re: [httpclient] Planning proposal
>
> ----- Original Message -----
> From: "Dirk Verbeeck" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, August 27, 2001 8:37 PM
> Subject: Re: [httpclient] Planning proposal
>
>
> > > ----- Original Message -----
> > > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Monday, August 27, 2001 12:55 PM
> > > Subject: [httpclient] Planning proposal
> > >
> > > > Here is a planning proposal for httpclient. Here are the steps that
> > > I'd
> > > like
> > > > to do (in that order) :
> > > >
> > > > S1/ Identify who are the current *active* committers. Rodney is one.
> > > I'd
> > > > like to be one also (I should already consider myself as one
> > > according to
> > > > the charter). Any more ? Remy, do you want to be one ? Any other
> > > persons
> > > > from Slide ? (those who do not answer to this message should not be
> > > > considered active I think ... :)).
> >
> > Why do want to do this ?
> > Private club to make the design decisions ?
>
> no, quite the opposite ... I'd just like to know who is working on
> commons-httpclient ... :-)
>
> >
> > >> S2/ Identify the list of changes made to the rlwrefactoring branch
> > that
> >
> > > > should be modified so that the Slide project would accept using a
> > > 1.0
> > > > release of commons-httpclient. I think it is important not to fork
> > > with
> > > > them, especially as they are the original donators of the code and
> > > we need
> > > > their feedback. So far, the interceptors should be returned and Remy
> > >
> > > should
> > > > clarify a bit more his idea with them.
> >
> > What is not changed ?
> > I just tried compiling the refactored HttpClient with Slide and got 100
> > errors. (compiler limit?)
> > And these are errors of missing/changed methods/classes; not deprecation
> > warnings.
> > Solving those would take a lot of efford, and all the current slide
> > users would have to change their programs as well.
> > For example: Credentials became abstract, method.name, method.setHeader,
> > GetMethod.getData, PutMethod.sendData,...
> > Even the basic things have changed...
> >
>
> 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).
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.
> > > > S3/ Formalise a bit more where we are headed :
> > > > - define a todo list of tasks for Release 1.0 and after. When all
> > > the
> > > items are finished we can release it.
> > > > - write a features page that lists the existing features of
> > > httpclient so
> > > > that end users could right know what httpclient supports
> > > > - write a simple index page for HttpClient that explains the project
> > > and
> > > the goal
> > > > - simple coding conventions
> > > > All these pages would go on the commons-httpclient web site
> >
> > Release 1.0 should be the version of july and should be a real release
> > with support by the HttpClient group.
> >
>
> Yes, that's what I also thought but Remy just said that Slide now contains
> it's own 1.0 and that commons-httpclient 1.0 could include the new changes
> (of course, I understand that he said this because he is disappointed with
> the way things have turned for httpclient. I personnally think we have
> really flunked this one and hope it will server as a lesson for the
future.
> I also believe that if everyone was putting some good will we could reach
a
> compromise where everyone would be happy, which is why it is important
that
> all Slide developers help steer the commons-httpclient so that it does not
> diverge from their needs).
>
> > > > S4/ Merge the rlwrefactoring branch into the main trunk and work on
> > > > converging with 2/ and 3/
> >
> > 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.
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.)
> > > > How is that ?
> > > > Thanks
> > > > -Vincent
> >
> > Another point to solve is:
> > Who is involved in design decisions?
> >
>
> Everyone. Anytime someone need to change something related to design, he
> should ask on the list for the change. Do we *all* agree to proceed like
> this in the future ?
>
> >
> > Regards,
> > Dirk
> >
>
> Let's try to correct our mistakes and work happily together.
>
> Thanks
> -Vincent
I'd like us to move forward as well.
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
