wpg-proxy-development

[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

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

[Alan M. <a_j...@ya...>]

John,

Thanks I will start looking at the code when I get a
chance.  Below are some spontaneous remarks....

> 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.

I presume that we would use ant only - do we really to
bother with make (aside from anything else you might
want to use it for) ?
 
> Alan,
> Take a look at it and see if you can figure out what
> I was thinking, 
[snip]

I'll play around with it can ask the relevant
questions later ;)

> 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.  

Junit good, in this case probably essential as we (and
end-users) need to be sure of quality and test
coverage.  If you like, consider writing the unit
tests first and do the implementation later, that way
you get an early idea of how idiomatic the library
code will be...
 
> 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.

Have you considered using a facade and hidding the
HttpClient stuff behind it (that way it can be
replaced easier later if no longer required?) - this
might be a secondary consideration though because the
concept still requires proving....

> 2. I also chose to use log4j for logging.  I really
> like log4j, [snip]

log4j also good! Some Apache projects prefer (and
sometimes irritatingly enforce) the use of another
logger e.g., commons-logging etc. but I still think we
should stick with log4j.

> 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.

Perhaps design first (e.g., UML) and implement later ?
That way we can see what you are thinking (literally!)
 BTW: I use the Umbrello UML editor

> 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 :)

...failing that women will flee us, children will cry
in our presence...no wait, that's what happens at the
moment.  ok things can only get better ;)

atb,
A.

---------------------------------------------------
You can find my GPG key (a_j...@ya...) at
ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/
---------------------------------------------------




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de