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