On Fri, Jun 08, 2001 at 08:32:22AM -0700, [EMAIL PROTECTED] wrote:
>...
> > The scoreboard is non-extensible. You may also recall that we were working
> > on a scoreboard design that was name/value pair oriented. Manoj disappeared
> > from httpd development, and the design impetus went with him. We threw out
> > all the partial work a while back and reverted to a 1.3 scoreboard design.
>
> We threw it out because it was the wrong design.
For the scoreboard, possibly. But my point was that we saw a desire to have
a flexible set of status information.
> > 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.
As Ian pointed out, having mod_status directly read the scoreboard means
that we cannot experiment with different scoreboard designs. The scoreboard
implementation can/should be changeable by the MPM. We can't do that because
of the hard-wiring between the MPM/scoreboard/mod_status.
> If you want to make mod_status extensible, there are two options.
I'm not talking about just mod_status. I also suggested the case where we
have a monitoring thread that grabs state and delivers it to a log, out a
custom port, tosses it to another server, ... whatever.
> 1) Make the scoreboard extensible, literally. This has been talked about
> for MANY months now. I started talking about it when I reverted to the
> 1.3 scoreboard, but the shared memory system still isn't in place that
> will allow this to happen.
The scoreboard is related to the MPM functions. I would disagree with this
notion. For my mod_dav status case, it would make no sense to put global
lock database stuff into the scoreboard.
> 2) Use filters.
Not applicable. Remember: we aren't talking about gathering data in response
to an HTTP request. The data could be gathered for other purposes.
> Modules can allocate their own shared memory, and add
> their data to the bottom of the mod_status output.
This does not provide for a monitoring thread. Or logging the status
information to a file. Or sending the status information to a database.
>...
> The problem is simple in my mind. The management app is the only thing
> that really knows what it wants to display information about. The module
> can try to figure out what the management app cares about, but 9 times out
> of 10, it will be wrong. So, either every module will log too much
> information, or it won't log enough. If you leave it to the management
> app to figure out what to log and when to log it, you resolve this
> problem.
The management app needs access to the various information that *could* be
logged. That access is provided by Ian's hook. The app gathers the data via
the hook, then decides what to do with what portion.
> > I do see that this can be useful. Consider the SSL certificate cache. How do
> > we get status on that thing? One of these days, I'd like to keep the DAV
> > lock database open (rather than re-open per request) and having status on
> > this global state would be nice, too.
>
> Both of those are solved by having each module create it's own shared
> memory segment and store the information in there. To display that
> information, that's a perfect example of why filters are so cool.
Filters won't help us with general status gathering.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
