|
From: John S. <jo...@we...> - 2007-01-13 23:29:39
|
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 |