mod_status idea

[Brian Akins <ba...@web.turner.com>]

I think this has been proposed before, but I wanted to see if there was 
interest before I started coding.

Currently, there is a static list of "states" that mod_status can 
report.  What if we extended this so modules could add there own state. 
  Perhaps use something similar to calls to "ap_get_request_note"?

Pseudo code:


mod_foo has the foo state:

in it's post_config:

int foo_state;

foo_state = ap_register_state("Doing foo");


then in it's handler (or filter, or wherever):

ap_set_state(foo_state).


Then mod_status would have an array (or hash) of int's to strings and 
report them:

5494 in state: "Doing foo"

The catch is we expect there to be a one character state.


This would allow a module to have multiple states (like a handler and a 
filter).  This would also make the state registration/setting voluntary.


Thoughts?


-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Re: mod_status idea

[Brian Akins <ba...@web.turner.com>]

Cliff Woolley wrote:
>  "optional" part is that the module
> that /defines/ the hook (and calls it) might not actually be present
> itself, so modules that wish to participate in that hook should not be
> broken by that other module's absense.


Okay.

So, I would something like this in a "caller":


static APR_OPTIONAL_FN_TYPE(ap_register_status_state) *register_state = 
NULL;
static APR_OPTIONAL_FN_TYPE(ap_status_state_set) *set_state = NULL;

static int foo_state;


in post_config:

register_state = APR_RETRIEVE_OPTIONAL_FN(ap_register_status_state);
set_state = APR_RETRIEVE_OPTIONAL_FN(ap_status_state_set);

if(register_state ) {
	foo_state = register_state("Doing foo");
}


then in my handler or filter:

if(set_state) {
	set_state(foo_state);
}


Or something similar?

-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Re: mod_status idea

[Cliff Woolley <jw...@virginia.edu>]

On Fri, 8 Oct 2004, Eli Marmor wrote:

> Please check, before adding dependencies on internal data of
> mod_status, if APR_OPTIONAL_HOOK can help here;
> mod_status.c defines a status_hook, and maybe it can be used to help.

Actually, we would want in this case would be an optional function, not an
optional hook.  It's a small distinction, but important: an optional
function is a function that can be called when needed, if present, by a
single caller at a time.  An optional hook is a type of hook, rather than
a single function call: it is a place in the API where a callback can
occur, and multiple modules can register to participate in that hook in a
certain loosely-specified order.  The "optional" part is that the module
that /defines/ the hook (and calls it) might not actually be present
itself, so modules that wish to participate in that hook should not be
broken by that other module's absense.

In other words:
                    callers                       callees
optional hook         ONE                          MANY
optional function     MANY                          ONE


I do like the idea in general by the way.

Hope this helps,
Cliff

Re: mod_status idea

[Eli Marmor <ma...@netmask.it>]

Nice idea.

Please check, before adding dependencies on internal data of
mod_status, if APR_OPTIONAL_HOOK can help here;
mod_status.c defines a status_hook, and maybe it can be used to help.

Brian Akins wrote:
> 
> I think this has been proposed before, but I wanted to see if there was
> interest before I started coding.
> 
> Currently, there is a static list of "states" that mod_status can
> report.  What if we extended this so modules could add there own state.
>   Perhaps use something similar to calls to "ap_get_request_note"?
> 
> Pseudo code:
> 
> mod_foo has the foo state:
> 
> in it's post_config:
> 
> int foo_state;
> 
> foo_state = ap_register_state("Doing foo");
> 
> then in it's handler (or filter, or wherever):
> 
> ap_set_state(foo_state).
> 
> Then mod_status would have an array (or hash) of int's to strings and
> report them:
> 
> 5494 in state: "Doing foo"
> 
> The catch is we expect there to be a one character state.
> 
> This would allow a module to have multiple states (like a handler and a
> filter).  This would also make the state registration/setting voluntary.
> 
> Thoughts?

-- 
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel