----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol"
<[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 4:11 PM
Subject: Re: [httpclient][VOTE] going forward
> > > Just a recomendation that you should feel free to ignore if you feel
> like
> > ;)
> > >
> > > However I would suggest not doing a release and not changing slide
just
> > yet.
> > > Why? Because that means that you are releasing software that you know
> you
> > > wont be supporting in future, and has many bugs. Instead just refactor
> it
> > > completely and nicely.
> > >
> > > Then in the future have slide change *once* rather than twice and
> > preferably
> > > provide adapter classes to bridge between two APIs. Remember users who
> > have
> > > to suffer through a changing API are less likely to come back and IMHO
> it
> > is
> > > better NOT to release something you know is buggy and you know you
will
> > not
> > > be supporting.
> > >
> >
> > Peter,
> >
> > I agree with what you say. That's even what Rod and I were previously
> > suggesting. However, we don't want to let Slide committers down and it
> seems
> > they really want to push for a 1.0 release that is exactly their code
base
> > (no API refactoring). If this is what it takes to make everyone happy
and
> > they can contribute to the projet I am all for it. Now, if Slide
> committers
> > are happy to keep their own httpclient version (the 1.0 of the
> proposition)
> > for the time and agree to help and consider moving to commons-httpclient
> 1.0
> > (the 2.0 of the proposition) if it brings nice improvements, then I am
> even
> > more for that ! I was just led to believe that this is no what they
wanted
> > from the last batch of emails. I just don't want to alienate anyone :-)
> >
> > I do think that your recommandation makes the most sense :)
>
> Vincent,
>
> Your proposal is not accurate, as it is possible to fix bugs and do what
is
> needed without breaking the API compatibility, except for a few very minor
> details.
> So please, don't say : "it's not possible to do anything without Rod's
> refactoring", as it's simply not true (of course, I think that's what he
> would want you to believe).
>
> For example, you can add multivalued headers by adding
> addHeader/removeHeader to HttpMethod. That won't break binary
compatibility
> in most cases (at least for people who used the abstract class). I don't
> why, but there seems to be the idea that you can't implement headers with
> multiple values with the original HTTP client, which is 100% wrong.
>
> So the problems mentioned will also get fixed by the 1.x branch (except
> without breaking API compatibility in any significant way).
>
I believe you are right. However what I was saying was to have a 1.0 release
that is the code from Slide and not make a lot of changes and bux fixes
before releasing it. That would be 1.1. Why ? Because we would like to work
ASAP on the main 2.0 branch. Also the idea is that, with everyone's help,
Slide uses the 2.0 version when it is ready. If your idea is to continue
working on the 1.x branch and make changes there then I don't think it is a
good idea and I completely second Peter in that case. Should that be what
you wish, then you should probably continue to use the httpclient you have
in Slide and work on it from there. We would work on 1.0 for
commons-httpclient and maybe one day you'll want to use commons-httpclient
and do the migration.
Tell us where you stand. If I understood correctly your last email you would
want to maintain 2 branches : a 1.x and a 2.x. This is what I don't like. I
agree to having a stable 1.0 and just making bug corrections. However
everything new, API modifications, ... should go in the 2.0 branch. However,
bear in mind that we can argue on a point by point to Rod's refactoring if
you wish but API stability should not be the keyword for the 2.x branch.
I'm trying to accomodate everyone ... Please help me out.
> Remy
-Vincent
