wpg-proxy-development

[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

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

Re: [Wpg-proxy-development] project structure

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

Hi Juan,

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

OK that's fine by me - saw something net-beanish
somewhere but no worries, I have a straightforward
build.xml so will go ahead with that.  I'll check it
in once I have finished testing all targets.
 
> 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...

Yes of course you are right! I'll look into your
suggestion and see if I can get my best test
infrastructure working. Junit is of course the right
thing for unit testing etc. I have added a separate
build tree to my build.xml for unit tests etc.
 
> Usage of callbacks  sounds like a good idea, I was
> also thinking about it
> but for filters
[snip]
> I'm looking for that UML...

...in that case I will create a UML directory in SVN
and checkin my diagrams - we can model from there -
I'll try get the details ironed out tomorrow.

atb,
A.


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

Re: [Wpg-proxy-development] project structure

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

Re,

I just found a lightweight http server that looks like an adequate start:
http://pygmy-httpd.sourceforge.net/index.html

i keep digging ...

Re: [Wpg-proxy-development] project structure

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

Ignore my last message, jetty(http://jetty.mortbay.org/) looks like a much
better (and supported) option.

2007/1/22, Juan Gonz=E1lez <ju...@ag...>:
>
> Re,
>
> I just found a lightweight http server that looks like an adequate start:
> http://pygmy-httpd.sourceforge.net/index.html
>
> i keep digging ...
>