hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Johnson" <e...@tibco.com>
Subject Re: 2.0 release - looking to the future
Date Thu, 26 Jun 2003 14:32:36 GMT

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...

 - 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);

 - 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);

 - void addHeader(String header, String value);

 - 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.


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:

View raw message