[Wpg-proxy-development] project structure

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

All,

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

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

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.

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.

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

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

atb,
A.












		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de