Rod,
This is a pretty impressive list and I am very much impressed ... ! :)
See my comments inline.
----- Original Message -----
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 10:02 PM
Subject: [httpclient] refactoring httpclient
> As you probably know, I've been working on a branch of httpclient to
address
> several issues that I believe prohibit a public 1.0 release, including
> several critical bugs, and several design issues that complicate or
prohibit
> fixing those bugs and adding new features in line with the httpclient
> charter and scope. Since that refactoring is nearly complete, and
Vincent's
> recent postings are beginning to press the issue, I'll open up my changes
Sorry to push ... :-) Hope the timing was not too bad ... !
> for discussion (not that they've been hidden up to this point). While
> personally I believe every one of these changes is a postive step, I'm not
> trying to ram them down anyone's throat either, I'm just trying to open up
> the discussion
>
> To obtain this branch of httpclient, simply run "cvs -q update -P -d -C -r
> rlwrefactoring" from the root of httpclient.
>
> As discussed below, there are docs, javadocs and tests that should
> demonstrate and document the use of this package.
>
> Below is an enumeration of the major changes I've made to the package,
> although there are probably other changes that I can't recall right now.
> I'd be more than happy to defend or discuss individual changes, although
> here my intention is simply to enumerate them.
>
> A few comments though:
>
> * Two decision points that I can't seem to make up my mind about are:
>
> (a) whether or not HttpConnection should be an interface (currently it is)
>
I don't see how an interface can be bad, so +1 for me with an interface.
> (b) whether or not Cookie should be an interface (currently it is not)
Fine with me too. We can also refactor later on.
>
> (My basic rationale is that generally speaking in components I think it is
> appropriate to make types into interfaces whenever it is reasonable to
> expect alternative implementations, as we certainly can with HttpMethod,
> probably with HttpState, but I'm more on the fence with HttpConnection and
> Cookie.)
>
> * As should be abundantly clear by now, but apparently it isn't, I have no
> issues with the concept of StreamInterceptor and ConnectionInterceptor,
but
> looking at the current interface the contract is not clear enough to be
able
> to add support for them. (And I would contend that the contract isn't
clear
> enough in the main branch either, given the inconsistencies and downright
> omissions I mentioned last week). If someone can clarify how precisely
> those are supposed to work, we can and should certainly work them back in,
> but absent that clarification, I don't see why we should maintain
> half-implemented support for them.
>
> * It has been (and still is) my intention to prepare the necessary patches
> for Slide to make it fully compatible with this refactoring. It should be
> relatively straightforward to do so.
>
That's great to hear ! That's really nice of you and I hope the Slide
committers appreciate this demonstration of good will.
> * Regarding a release plan, I'd suggest the following (more or less in
this
> order):
>
> (0. As I've always maintained, if we want to release the current main
branch
> or any previous revision of the main branch as anything short of a 1.0
> release (say 0.9), I'm not opposed to that. I am opposed to releasing
> releasing the current main branch as a 1.0 release. Why? Because we know
it
> has fairly critical problems, and we know that much of the API is likely
to
> change to address those problems, so why pretend that it is a stable
> release? (Not that my personal opinion can, should or *has* stopped
anyone
> from calling for or voting for a 1.0 release with the current main
branch.))
>
> 1. Let's review these changes, make additional changes (or perhaps undo
> changes) as warranted, and merge them back into the main branch.
>
I'm +1 for them as listed below.
> 2. Let's resolve the logging stuff one way or another. Personally, I'd
like
> to see us accept the logging proposal and migrate HTTPClient over to using
> it. I found the logging extremely useful though, and I expect I will
> continue to, so I for one would be opposed to removing all logging from
> httpclient outright. I suppose conditional compilation is one other
option.
I would say, let's keep it with the Log wrapper as it is now and we'll move
it to the commons logging stuff when it is ready. We have enough work to
start with.
>
> 3. Let's make sure Slide *can* work with the revised HTTP Client (i.e.,
that
> it supports all of the functionality strictly required by slide), and
leave
> whether or not they choose to up to them.
>
+1
> 4. Let's release the resulting code base as the 1.0 release.
+1
[snip]
I'm +1 for merging the rlwrefactoring branch in the main trunk now, discuss
issues with Slide committers and solve them to everyone's satisfaction.
Thanks for all your efforts and time.
-Vincent
