----- 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).
> > > 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 :)
> > > 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
