> > I don't agree with the project's direction. For example, Rodney just
> removed
> > the interceptors. So I won't endorse or use the post 1.0 version ...
> > However, I may need a few of the features which will be added after 1.0
> > (digest support, etc), so since it's been next to impossible for me to
> > influence this component, I don't see how I can avoid having to fork it
> > back.
> >
>
> Why don't we do it in an apache way ? If someone wants to perform
important
> changes to the source, he should ask it on the list. However, everyone
needs
> to display good faith and it should not be vetoed because it means some
> additional work for Slide to use a proposed change. I'm sure Rodney would
be
> happy to put back the interceptors if need be. I don't see myself why they
> should be removed.
Well, ok, but it's not worth it for Slide to have to spend a lot of time
following the API changes in HTTP client. Slide wouldn't get anything in
return, so I cannot justify doing it.
> If I understand correctly :
> * you're using a slide version of httpclient for now, meaning the commons
> httpclient should be considered as not released code and we can modify it
> for a 1.0 release later on
> * you would be willing to use this 1.0 release later on provided it is not
> too different from what already exists in Slide. Interceptors should stay
> for you to use it. Any other things that have been removed or changed that
> you would like to see in 1.0 ?
Maybe.
> I propose we identify the list of features we would like in version 1.0
(in
> a features page and todo list) so that everyone will be happy. Once these
> goals are identified, we all work on it.
As I said, I have no incentive at all to do this, and I lost my motivation
to participate in HTTP client after the incidents about the logging and
Dirk's commit access. So if 1.0 is binary compatible or almost binary
compatible, I'll use it. Otherwise, I won't.
Remy
