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

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

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

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

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

      -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.
      -filter creation for persistent statistics (say keep all GET requests
on file gets.txt)
      -rule creation for traffic control (don't serve such or such type of
request)
      -configure caching rules: maybe we should add some caching facility
      -just about anything we can do programatically, but through a web page
(of course not everything, but common things)

What do you think of all this?

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...'
> 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... ]
> 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&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wpg-proxy-development mailing list
> Wpg...@li...
> https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development
>