[Wpg-proxy-development] Code is all ready now

[John S. <jo...@we...>]

All,
The svn repository is looking pretty good now, Juan has converted my little
mess into one big mess, and you can still compile on the command line.
I put a makefile in the root so my :make will still produce the desired
results, and added a quick distribution method to the build.xml so I can
easily get updated javadocs onto our web site.

Alan,
Take a look at it and see if you can figure out what I was thinking, the
Proxy.java contains all the nonsense I was trying to do when a CONNECT
method is seen.  I will be out of pocket most of the day tomorrow, but will
be back in action on Monday feel free to verbosely query me on any code that
is not well documented and not very intuitive.
Juan has already fixed two issues he found in the base, and I am sure some
others are just hanging around. ;)

I will try and start documenting the interface as I have been using it and
adding some inline examples/documentation so the javadoc can be a single
point of reference, as well as a brief how to of some sort.

Juan,
I have not even looking into adding JUnit support but realize a test suite
would be of great value for this thing as we chug away at it.  Do you feel
like adding a couple of hooks or test routines that I can fill in with you?
I originally envisioned writing a separate method to test all the listed
features but never got around to it.  Something that would let us run a
series of quick tests to ensure functionality would help after a build.  I
wasn't sure if it would require a separate class that throws http
connections at a running proxy and checks for success/failure, or what?  Any
thoughts on this line?

We are off to a great start, hopefully we can finish up the HTTP/1.0 support
soon and get this thing rolled out for others to abuse and start reporting
problems with.  Hopefully, once those bugs start stabilizing we can start
trying out all the HTTP/1.1 features.  I didn't necessarily make a conscious
effort to NOT support HTTP/1.1 but whenever faced with an implementation
option that called for too much more work to support a new feature of 1.1 vs
1.0 I opted for the latter.  

I am really surprised this library hasn't come around sooner, I hope it can
be plugged in easily enough to get more applications using it, and thus more
bug fixes and features supported in the future.

Some design decisions to note:
1. I am absolutely addicted to the Jakarta commons and I'm even considering
naming a child Jakarta, so we are using the HttpClient library from that
Apache project, it was easy and already in other parts of my application at
the time.  However, this should not become a weight around our necks, it is
not so difficult to use the standard java URLConnection handlers to pull the
required data back, so if someone comes along and decides those guys are
communists and the implementation should not be dependent on that, let them
enjoy freeing us from the dependency.
2. I also chose to use log4j for logging.  I really like log4j, and see no
reason to stop liking it, I believe there are techniques to replace it if
someone is so inclined, but please do not do it to the project svn
repository, that would suck.
3. the logic for applying filters and processors may need some review, in a
few places I wasn't sure which method to call so I tended to call the method
I had the most data available to send, which may prove shallow and
unpredictable during implementations, I will try to organize a way to
articulate the logic as it exists today.

And that is my typing quota for the day, good luck and thanks again for
joining this effort, may you all become immortal for your efforts, women
will flock to you, children will sing songs of praise, Porsche will name a
car after you, and one day you will evolve into pure energy and come to know
the true nature of God.  Or something like that :)
Thanks, John