hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: 2.0 release - looking to the future
Date Sun, 29 Jun 2003 21:45:13 GMT
Mike,
It does sound like a good idea to me, but could not it wait until 3.0,
as it does seem to be exactly what Eric has been proposing as a
"framework of interfaces"? Are there any pressing reasons for having it
done within 2.1 release? Would it be a bit too much of a change? 

Oleg



On Sun, 2003-06-29 at 17:46, Michael Becke wrote:
> All good ideas I think.  I agree with the separation for 2.1/3.0.  I 
> have one item to add to the 2.1 release.  I would like to rework the 
> HttpConnectionManagers to add support for connection factories and 
> perhaps a few other things.  In particular I would like to move the 
> creation of connections out of the managers and add support for 
> closing, releasing and stale testing with the factory.  It might look 
> something like:
> 
> 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:eric@tibco.com]
> > 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: 
> > commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: 
> > commons-httpclient-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 
> > commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: 
> > commons-httpclient-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message