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
