httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject RE: Hooks for management reporting (was RE:New Hook)
Date Fri, 08 Jun 2001 17:42:31 GMT

> > > In another note, you mention shifting this from the
> > scoreboard code to the
> > > MPM. I don't see that as true. We can have the scoreboard
> > code implement the
> > > hook. If/when we ever desire to: we can migrate the hook
> > response from the
> > > scoreboard to MPMs. Or individual MPMs can add their own hook.
> >
> > Doesn't really matter if the code lives in the MPM or the scoreboard
> > itself.  What is being proposed, is having a scoreboard that
> > keeps track
> > of the information, a segment of code that converts the
> > scoreboard to an
> > internal table, and a segment of code that converts that table to the
> > output for the management module.  Just remove the middle piece.
> >
>
> here's what I am proposing.
> that mod_status no longer needs to know the internals of the scoreboard (making replacing
a scoreboard
> later on easier)
> that the hook outputs a series of name/value pairs.

Why are we talking about replacing the scoreboard?  What we have works,
and makes sense.  We tried using name/value pairs before, it doesn't work.
There is no good way to define the name/value pairs.  Again, you are
talking about taking a rich communication medium (the scoreboard), and
translating it into a poot medium (this name/value pairs).  The scoreboard
has all sorts of information that is stored in the make-up of the
scoreboard.  For example, anything that is an int in the scoreboard
actually conveys more information than just the actual number.  Going to
key/value pairs, means that we lose that intrinsic information.

> These name/value pairs could come from a subset of
> either the APM MIB (http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-apm-mib-03.txt)
> or the WWW-MIB http://www.ietf.org/rfc/rfc2594.txt
>
> the management module wouldn't need to understand (or have access to) all the internals
>
> This could be done via filters, but I was thinking that there could be multiple management
modules.
> one in HTML format for users, another in XML for automated responses, and another possibly
in SNMP
> all with different output requirements
>
> or are you thinking that the 'scoreboard filter' would dump to name=value pairs, and
the management module
> itself would be a filter sitting on top of it?

No.  The scoreboard is just a shared table.  Mod_status uses the
scoreboard to output information about the server.  Any other filters that
are invoked would be responsible for adding their out status information
to the status page.  The fact is that most management modules won't be
using the handler or filter phase.  For example, mod_snmp can completely
ignore those phases.  That module just gathers information, and outputs it
to the SNMP agent in the logging phase.  There is no need for a filter for
mod_snmp.

If you want the scoreboard to be output in XML, then you just create a new
status module that outputs information in XML.  Then, the obvious second
step is to remove the current mod_status, and replace it with a filter
that converts the XML to the proper HTML for the status module.


Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------




Mime
View raw message