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
