Thanks for starting this discussion. I've been contemplating this one for a while.
My development approach follows along the lines of "revolution through evolution". Which means, with respect to HttpClient, that on the one hand I don't want to encourage too many fundamental changes for the existing APIs, except perhaps introducing a modicum of additional flexibility, while at the same time building a completely revolutionary framework on top of and underneath the existing structure. Having said that, I see 2.1 as the first step in the evolutionary path, while building the framework that makes 3.0 possible.
Evolutionary - 2.1 release:
- 16729 - Cross host and port redirects - this bug has the most votes - although the projects we have don't need this, I think the flexibility it implies is good.
- 10792 - Plugin authentication modules - I'm not sure what this means exactly, but it sounds like it adds flexibility, and I'm thinking that authentication could be handled in such a way that "callbacks" to a client were obvious and transparent
- My current personal peeve - a better test framework than SimpleHttpConnectionManager, that allows us to more closely mimick real HttpConnection behavior, thus enabling more tests without actually requiring a real connection. Based on missing test cases, I think we desperately need this, especially for people like me who are not in a position to test NTLM authentication, or proxies, without at least considerable difficulty, if at all. Wouldn't it be great, for example, if we could "test" proxy support without actually having to have a proxy server hanging around (that Squid proxy comes to mind...). That would mean that we could even test both proxied and non-proxied actions without running a separate set of tests under a new configuration.
- Try decoupling classes - JDepends reports a few cycles that might be worth breaking if we can.
- A better "configuration" mechanism. I'm thinking of the javax.xml.parser.SAXFactory interface, where you call "setProperty" on the factory. I'm thinking that we currently have a variety of "hidden" properties, which we could unify with a single exposed Properties object that the user could configure to their preferences. And we could probably define some sort of look-up for a httpclient configuration on the classpath, so that clients could simply add one file to their classpath and have their HttpClient communications configured. For examples of "hidden" properties and not so hidden properties, consider the following list:
* the default connection manager * the "timeout" * the "connection timeout" * the connection factory timeout * "strict" mode - what is this used for, by the way? * follow redirects * protocol factories * cookie policy * - default headers on a request - nice to have....
I'm sure there are others. Making all of these "defaults" configurable with a "deployment descriptor" otherwise known as a property file in the classpath would be a boon to clients.
I might just recommend stopping there for a 2.1 release - with the idea that we release early and often. This would, of course, mean another list for the 2.2 release. Undoubtedly others have a different set of issues that might be more appropriate for 2.1, but whatever that list is, I would suggest that it be *short*.
For a 3.0 release, I lean towards a radical redesign built on top of the current code to start.
The radical redesign would be built around a framework of interfaces. The general idea would be that we expose only one or two key implementations of the interfaces, with the implementations of everything else being hidden behind a "factory" facade.
The following is a "for example" to get the idea across, not any attempt at real interfaces...
IHttpClient
- IHttpMethod newMethod(String verb, String url); /* not clear to me whether there should be a separate "newGetMethod", "newPostMethod", "newPutMethod"...) - there are advantages both ways */
- void setProperties(Properties defaultSettings);
- void setProperty(String propName, String propValue);
- void addDefaultHeader(String header, String value);
- String removeDefaultHeader(String header);
IHttpMethod
- int execute() throws xxxx; /* note that in the interface construct, the interface keeps "track" of its http client, so execute can be called directly on the method */
- IHttpRequest getRequest();
- IHttpResponse getResponse();
- void setQueryString(NameValuePairs[] pairs);
IHttpRequest - void addHeader(String header, String value);
IHttpResponse - String getHeader(String header); - IStatusLine getStatusLine();
and so on.
Note that I don't particularly like that I stuck the "I" in front of existing class names just to make them interfaces, but it did it to get the point across and avoid confusion with existing classes.
A cool part of this approach is that we can start writing the interfaces, and the implementations of the interfaces right away (we don't really even need to fork the code). Until we actually get to the 3.0 release, we can treat the interfaces as the "less capable" access to the functionality, and release 3.0, only when the functionality exposed by the interfaces exceeds that of the current class implementations. Along the way, I suspect we'll find we can start to deprecate and eventually "hide" (package level protect) current exposed implementation classes, especially where the interfaces start to supplant them.
Just throwing out my thoughts.
-Eric.
Michael Becke wrote:
I think we are quite ready for a beta2/rc1. I agree that there have been few new bugs lately but I would still like to see a beta2, just to be sure.
As part of beta2/rc1 we were planning to branch out 2.0. Before we do this though I think we should have a better idea of what we want in post 2.0. In particular I think we should brainstorm about features we would like and then decide if they will fit in 2.1 or 3.0.
Mike
On Thursday, June 26, 2003, at 01:10 AM, Jandalf wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
