Re: [Wpg-proxy-development] What should a web interface contain?

[John S. <jo...@we...>]

Hi John,
first, sorry for the delay answering, but I had a bad combination this week:
many work + bad cold + notebook crash, when I came back home I just had no
strength to answer (or even read) any mail :(



[Southerland, John B] No Problem at all, I was beginning to get worried
everyone was upset at all my annoying additions ;)


Now, hands on work, I've looked at your actual implementation of
ProxyStatistics and your additions to the Proxy class, and they made me feel
like the Proxy class is getting quite heavy, now it's doing most of the job
including: reception, parsing, processing and responding to any request. For
me, it seems more reasonable to extract every possible functionality from
it, starting with all the local requests for statistics, and delegating all
the processing to leave the Proxy class more like a functionality caller
than implementer (This is more a refactoring process anyway). My proposal is
to separate the Proxy class in: 




      - ProxyProcessor: Final class with methods extracted from Proxy to
handle each received request. This class implements the (Runnable |
Callable) interface, read a bit more to know why. 

[Southerland, John B] That does make sense to me, considering the HTTP
nature of the transactions, we don't need to track any information between
requests.


      - ProxyRegistry: Here we keep every HttpMessageHandler/Processor in an
static environment. Provides public static methods to register/unregister
handlers and processors, and protected static methods to call each
handler/processor with each HttpMessage. 

[Southerland, John B] Wouldn't we just end up having to wrap all the calls
to addHandler and addProcessor through the main proxy or would you recommend
adding something like Proxy.getProxyRegistry().addHandler( new
MyHandlerObject )?

I guess I can see that :)


      - Proxy: This class keeps doing the loop to receive each new request,
and also has a ExecutorService(fixedThreadPool) of ProxyProccessors to
process each request, that's why ProxyProccessor implements Runnable or
Callable, we should decide whether it should return something or not,
returning some data may be a good way to populate statistics... 

[Southerland, John B] or perhaps register a ProxyStatistics object and allow
it to use synchronized methods to update it?


      - Extract the html construction and detection to ProxyStatistics, or
even including an interface and default implementation for something like
ProxyStatisticsFormatter, but this depends on how many functionality we end
with in the web page. 



[Southerland, John B] I agree that the html construction should probably be
done in the ProxyStatistics object, though I am not sure we need to go so
far as to create a plugin hierarchy for it, as it may only benefit us in
debugging the proxy itself, though other developers may need that as well.
Hopefully we can expand it to support the entire scope of possible usage
without having to go overboard.


About the web page, the question I see is how lightweight do we want our
library to be. I can think few features to add to that web page, but it
feels like they maybe out of scope or overwhelming for a lightweight library
(anyway some would require extra functionality to be added to the library): 

[Southerland, John B] Maybe we should enable property configuration, to
allow for all the features?


      -pass protection: This is a must have, I think. As an initial solution
we can add a new singleton class like ProxyWebUsers to keep track of
authorized users and put some authorization mechanism within
ProxyStatistics. 

[Southerland, John B] Agreed, in fact we may need to support quite a bit of
authentication, to allow developers to enable users of the proxy at runtime
and not just accept all traffic, for instance on my machine here, I use the
original version of this library to record web scripts for performance
testing.  One of the problems I have is that ANY http traffic coming from my
machine gets routed through my temporary proxy, I would rather have the
ability to authenticate the particular browser to allow me to record yahoo
weather update free performance scripts.  This would also apply to the proxy
statistics query.  In the future it would also allow developers to create
context sensitive proxy's that allow some users different features than
others.  We should definitely explore this further.


      -filter creation for persistent statistics (say keep all GET requests
on file gets.txt)

[Southerland, John B] I was just about to write a log4j plugin to handle
collection all messages and look into adding support for more detailed
queries to the internal web server to handle viewing logs.  Though an issue
of storage and size does become an issue. I am pretty crazy here, and wanted
to take a breath before creating a sql server to store all those log
messages, or an ever growing array :(


      -rule creation for traffic control (don't serve such or such type of
request) 

[Southerland, John B] isn't this the entire point of the Processors?  I
wouldn't want the web interface to turn into a proxy admin interface, just
query, or read only type operations.


      -configure caching rules: maybe we should add some caching facility

[Southerland, John B] this may be a separate topic, we could implement the
Cache-Control options, but I would want to make that a configuration
property, since my stuff does not like cache, and I'm sure others may need
the same.


      -just about anything we can do programatically, but through a web page
(of course not everything, but common things)

[Southerland, John B] as I said in the rule creation section, I would like
to keep the web page to stats only, otherwise we are becoming a full proxy,
and we will have to deal with an entirely new set of users..

End Users ;) Ugly



What do you think of all this? 



[Southerland, John B] I love it!  Let me clean up the proxy stats stuff, and
move the html generation to the object itself, as well as a few helper
functions, and registry of the Proxy class until the refactor of the Proxy
moves handlers into another class.  Would you like to take a go at
refactoring the Proxy and breaking it up as you discussed?  I will be happy
to sit back and let you hack away .


Regards.
PS: I must go out for at least one hour, but i'll be back as latest by 21:00
UTC 

2007/2/2, John Southerland < jo...@we...>:

Lol, did I say something wrong?



-----Original Message----- 
From: John Southerland [mailto:jo...@we...]
Sent: Wednesday, January 31, 2007 4:57 PM 
To: ' wpg...@li...
<mailto:wpg...@li...> '
Subject: RE: What should a web interface contain?

SVN updated, we have a basic web page returned with usage statistics
presented via a web page when you point your browser at the proxy. 
I added several methods to enable/disable this capability, and still need to
write a log4j appender that will collect 50/100/500 messages in a stack for
us to display in this page, but I will wait until we iron out the details of

what this page should do, and how it should do it, please respond whenever
you can to the questions in the original email, I hope this capability isn't
just an annoying window dressing that no one really wants. ;) 
Thanks, John


-----Original Message-----
From: John Southerland [mailto:jo...@we...
<mailto:jo...@we...> ]
Sent: Wednesday, January 31, 2007 11:13 AM
To: ' wpg...@li...'
Subject: What should a web interface contain? 

Team,
I have been thinking about expanding a feature of the proxy server itself. 
I want to make sure the proxy remains a simple library but I realize we also
need some level of instrumentation to allow us to debug and give developers
a simple way to troubleshoot their code.  I had always intended to add a 
simple web interface that will allow people to point their browser directly
at the proxy and get usage statistics.

This is a little tricky, but if we get a request that is not destined for a
remote host, but the proxy itself, then we can ignore the rules and return 
some statistics such as:
Number of processors and handlers registered
Connection statistics such as number of requests processed and the
success/failure counts as well as durations
A simple log display of the last 50/100/500 messages logged 

What other information would you like to see in a status page?
Should we user/pass protect this information?
Possibly allow enabling or disabling this feature via enableStatusBrowser(
Boolean ) and isStatusBrowserEnabled() methods? 
Does this even seem useful?  Or does it seem more "window dressing"?
I know I personally don't worry about such trivial things while developing,
but I wrote the stupid library, and know somewhat what is happening via 
log4j.

I don't want to stop the progress going on, but think I can work this into
the code without breaking anyone elses changes.
Thanks, John


------------------------------------------------------------------------- 
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo 
http://sel.as-us.falkag.net/sel?cmd=lnk
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
&kid=120709&bid=263057&dat=121642 
_______________________________________________ 
Wpg-proxy-development mailing list
Wpg...@li... 
https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development