I agree with C and will support it. I do not think that Rod's refactoring
belongs back in the sandbox. He is on his own branch, doing his own thing,
and will call for a vote when he wants to bring that code back. The 2.x
main and 1.x branch philosophy will allow a win-win in my opinion.
Scott Sanders
> Good summary, it seems pretty accurate to me.
>
> My preferences would be, in order, C and A. C provides a smoother upgrade
> path by making bug fixes etc. to the main branch more accessible, but A
> insures that nobody downloads the wrong JAR. I'm not a big fan of B, and
I
> recognize the difficulties of D.
>
> I think nearly everyone who has looked at the refactored interface prefers
> it, so it seems like not releasing the refactored code (option B) is not
> doing service to the users. If we pick C, I'd like to specify that the
1.x
> and 2.x versions are both maintained, but that the 1.x branch is more
> specifically oriented toward Slide compatilibity.
>
> - Morgan
>
> ----- Original Message -----
> From: "Dirk Verbeeck" <[EMAIL PROTECTED]>
> To: "Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, August 28, 2001 2:27 PM
> Subject: [HttpClient] An overview of the different alternatives
>
>
> > There are already many proposals out there, with counter proposals and
> > appendices. Let me try to summarize them. I'll start with explaining why
> > this is a big deal for the slide team.
> >
> > First the versions that we now have:
> > � Slide HttpClient
> > � Commons main HttpClient
> > � Commons refactor HttpClient
> >
> > Slide is using its own version of HttpClient. It is distributed together
> > with extra Methods for WebDAV support. There is a wrapper class to
> > reduce the code for simple cases but the HttpClient is also used
> > directly (like you normally do).
> > If you break compilibility you have to fix the extra WebDav Methods, the
> > wrapper class and all programs using HttpClient. You force all the slide
> > users to change their programs as well.
> >
> > This is what the slide team finds not acceptable, "why?" you might ask.
> >
> > I (and others) believe that all errors can be solved while keeping the
> > API intact.
> > Maybe add a new method here and there but nothing major.
> >
> > Do we need a new API? Maybe, but my first reaction would be implement
> > the HttpURLConnection interface. Saying that most users want a new API,
> > is not correct, they want the bug fixes and those should be possible
> > with minimal changes to the API.
> >
> > On the other hand the refactored version already has the bug fixes that
> > everybody wants.
> >
> > What to do?
> >
> > a) Keep the slide version (maybe even change the package name back to
> > slide) and make the refactored version the commons one.
> > The slide team continues improving and making bug fixes on their version
> > and the commons team does the same on their version. (you can be on both
> > teams if you like).
> > When we decide to make a slide 2.0 that breaks compatibility, slide can
> > start using the commons version if needed but we don't expect this to
> > happen in the following 6 months and by that time all bugs will be
> > solved in the slide version as well. (Even faster as we get more and
> > more users)
> >
> > b) Make the slide version the first commons release 1.0. We continue bug
> > fixing on this version (maybe some small enhancements like support for
> > HttpURLConnection). When all bugs are solved we do a next release 1.1.
> > After this we can design custom APIs for different applications, from
> > testing framework like latka to event driven swing applications. The
> > refactored API can be one of them. In the meantime the refactored
> > version lives in a branch or in the sandbox.
> >
> > c) Release the slide version as 1.0 and the refactored version as 2.0.
> > Version 2.x continues as the main and 1.x as a branch. This is the same
> > as option a, some people will continue to use 1.x and some will use 2.x
> >
> > d) Release the refactored version, break compatibility on the slide
> > client API, and force all slide users to do major changes on their
> > programs.
> >
> > Any other alternatives ?
> >
> > The current proposal is C. Is this correct?
> >
> > One drawback of option C is that you can't use slide client in the same
> > VM together with commons HttpClient. For your own programs this is not a
> > problem, slide webdav is a superset of commons http but having 2
> > different APIs with the same name can give problems.
> > There is already a slide user that used the commons HttpClient by
> > mistake.
> >
> >
> > Dirk
> >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
