interface HttpConnectionFactory {
HttpConnection createConnection(HostConfiguration);
boolean isConnectionStale(HttpConnecton);
void closeConnection(HttpConnection);
void destroyConnection(HttpConnection); }
And perhaps another interface that can be registered with a ConnectionManager. This one would be useful for tracking connection use.
interface HttpConnectionManagerListener {
void connectionCheckedOut(HttpConnecton);
void connectionReleased(HttpConnection); }
These are just a few quick ideas ideas to throw into the mix.
Enjoy,
Mike
On Thursday, June 26, 2003, at 11:02 AM, Kalnichevski, Oleg wrote:
Eric,
Fantastic proposal that I whole-heartedly support. Let me present my own more condensed version with a few omissions (that are not critical at all)
2.1 release:
- Better exception handling framework (bug #19868)
- Cross-site redirect fix. Authentication, redirect & retry code moved from HttpMethodBase to HttpClient
- New configuration architecture that includes plug-in mechanism for cookie policies & authentication schemes
- More reliable header parser. Recently quite a few people requested a fix for bug #11240
- Decision of new external dependencies: commons-lang, commons-codec
- Ability to abort requests (bug #20288)
- Removal of deprecated stuff, such as UrlXXXMethod classes, disk buffering in GetMethod and so on
3.0 release:
- I fully support the proposed concept of a framework of interfaces
- I really would like to see HttpMethod interface split into HttpRequest/HttpResponse pair and the concept of recycling of HTTP methods gone for good
- HttpClient skiing & snowboarding weekend
Cheers
Oleg
-----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 16:33 To: Commons HttpClient Project Subject: Re: 2.0 release - looking to the future
Mike,
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
