Re: [Wpg-proxy-development] project structure

[<ju...@ag...>]

Hi back,
  (scroll down for comments)

I have been going over the code and putting together
> ideas on how to structure the project so that we are
> clear on what needs doing.  I'd like therefore to make
> the following suggestions...apologies now for the
> longish post :)
>
> * can we keep the build mechanism simple, i.e., drop
> the Makefile etc. along with any tool specific
> materials (e.g., netbeans generated build files etc.)
> - this doesn't mean you can't use that sort of thing,
> just keep it to youself ;) i.e., don't check it in.  I
> have prepared a simple build file + properties etc.
> that does all the usual things (e.g., clean, compile,
> javadocs etc.) - I'll check this in (and do the other
> svn jobs) if no-one has an objection here....


This is not an issue for me as  I can locally work with a Netbeans project
with files linking to a local copy of the repository, anyway I thought the
current svn code didn't include any netbeans-specific file,  but I agree the
it may be a bit too complex for our simple project.

* could we not distribute depedencies with the project
> (!) - these are not our JARs so we should not be
> looking after them :) I recommend using ivy for
> depdendency injection, i.e., in the build.xml that I
> will check in there is a "cache" task that goes off
> and gets all the JARS for you and puts them into your
> lib directory - its _very_ simple and we do not have
> to think about JARs themselves (it even downloads the
> right version and manages conflicts etc.)


I didn't know about ivy but it sounds interesting, and if you already have a
working build.xml for that it's fine with me.

* I think we all need to be very clear about what the
> proxy does and does not do (later I'll post a comment
> about some SSL difficulties which we may have) -
> therefore I am just completing a test/server pair to
> simulate a HTTP client/server, we can then place our
> proxy in between the two and observe/test what happens
> etc.  I suggest we use/improve/amend this basic test
> infrastructure to make sure we can always test that it
> is working the way we want.  For now I will focus on
> HTTP - if we agree on details we can move to HTTPS
> later etc.


As you suggested in some previous mail, JUnit maybe a good candidate to test
things like that. but why not going for some already developed  java http
server? As we only need it for our own testing sounds reasonable to avoid
debugging an http server...

OK, and now to the design itself ;) I looked at the
> Proxy class and see how it is intended to work but
> think we could follow a few lessons from similar
> projects (and native proxies.) Therefore I'd like to
> suggest that we use the Proxy to implement a template
> method using callbacks (=sort of processors in the
> current design.)  This means that Proxy is an
> intermediate server that has a simple pubic interface
> that relays requests/responses.  Proxy is configured
> at instantiation with lists (e.g., arrays) of request
> and of response handlers (in each case a callback
> handler implements a certain interface) and does
> nothing but maintain state information and invoke the
> callbacks in configured order, i.e., it follows a
> well-defined handler cycle.


Usage of callbacks  sounds like a good idea, I was also thinking about it
but for filters

I'm writing up some UML to make these points precise
> but I think it is a recognisable way of doing it from
> a network programming point of view and should make
> implementation pretty easy.  There are of course other
> little details (failures via exception only,
> threading, etc. etc.) but I think if we agree on the
> big picture then I think we can sort out the little
> details later.


I'm looking for that UML...

BTW: I use Umbrello for UML - is that ok for everyone
> (I can always PNG output for discussion purposes.)


That's  OK for me (and Umbrello follows the omg specification so it should
be importable in any moden UML program)

OK, that's all for now - I'll follow this up with my
> PNG post and we can take it from there.  Feel free to
> feedback/comment etc. thus far.....
>

We'll speak later