httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: hooks
Date Wed, 21 Jun 2000 00:32:08 GMT

> > > What is the reason we have hooks (2.0) based on function name (ala
> > > ap_hook_fudge, ap_run_fudge) rather than some key (ie
> > > ap_add_callback(fudge_hook,...), ap_call_hook(fudge_hook))? I'm sure there
> > 
> > Because each hook has a different prototype and we need to be sure that
> > modules use the correct prototype.  Having a single function that just
> > calls the right stuff under the covers means that we can't do real
> > argument checking at build time.
> 
> Type safety at build time can be a good thing, but if its at the cost of
> having modules exposing hooks to other modules it might not really be worth
> it. Ie, how will linking issues be solved in Windows (or AIX) where all
> symbols must be resolved in the dll (or .so)? It seems now the mod_* will
> need to have the AP_IMPLEMENT_HOOK_* and AP_HOOK_STRUCT in its shared
> library, or am I missing something?

I believe you are missing something.  :-)  I assume you are talking now
about a module that wants to provide hooks for other modules to register
for.

The AP_IMPLEMENT_HOOK is a macro, and it will never need to be exposed
through a .def or .exp file.  The symbol that is exposed is the generated
symbol.  This means, for example, that ap_hook_check_user_id is exposed,
but not AP_IMPLEMENT_HOOK  (which is the macro that generates the
ap_hook_check_user_id function).

AP_HOOK_STRUCT is also not exposed, because it is a static variable.  It
took me a long time to see how this all fits together, but here it goes:

when you declare AP_HOOK_STRUCT at the top of a file, that defines:

static struct {
    ap_array_header_t link_(first_hook_name)
    ap_array_header_t link_(second_hook_name)
    ap_array_header_t link_(nth_hook_name)

}

Then, at the bottom of the file you use the AP_IMPLEMENT_HOOK_* macros to
actually generate the relevant functions.  There are two functions
generated.  The first basically add a function pointer to the hook, and
the second loops through the hook calling the functions.  The first is
ap_hook_(hook_name) and the second is ap_run_(hook_name).  The first is
public and needs to be put into the .def or .exp file, but the second is
static and should not be exposed.

The final piece to all of this is the AP_DECLARE_HOOK that goes into the
header file.  This just declares a couple of prototypes, and sets up the
LINK_(hook_name) structure to be used for inserting new hooks.

This should explain how things are shared or not shared in a relatively
straight forward manner.  Please if this doesn't help, let me know.  Ben,
if I have this completely wrong, please correct me.

> > The fact is that an Apache Module will ALWAYS be dependant on which Apache
> > it is running on.  It is unrealistic to think that a module can figure out
> > where it should add a hook at run-time.  Those kinds of decisions need to
> > be made by the programmer.  For example, if I have a module that provides
> > the auth_checker_hook, how would you propose that module would determine
> > which hook to use?  
> 
> Yes the programmer needs to decide where it needs to be hooked, but since
> we're using hooks instead of single function pointers, one can assume how
> the call is directed to be transparent. 

It would really help me out if you could give an example of what you are
thinking here.  I am having a VERY hard time parsing this.

> But this hooking mechanism seems to be less than useful when modules want
> to create hooks for other modules. I guess what I'm wondering is why it has
> changed so significantly from 1.3?

If a module creates a hook for other modules, then this implies that the
first module is always in the server.  This is just not the case with
Apache, and we do not code for that case.  For example, say mod_foo
implements a hook and mod_bar registers a function for it.  if mod_foo is
not in the server, then mod_bar has no place to be registered.  This is a
bad thing.

It has changed so siginificantly from 1.3, because in 2.0 we didn't want
the order of the hooks to be dependant on the module.  The hooks needed to
be independant of each other.

> > Are you saying the proxy implements a hook that closely approximates what
> > the server is doing, and you want all of the modules that registered for
> > the server's hook to also register for yours?  This is IMHO a bad thing to
> > do, but it is possible to do it.  It requires a big hack, because it a bad
> > thing.

> Yes I guess I mean the latter, if a module came along and wanted to reuse a
> hook for something "similar" to what the hook was originally for - I'm not
> sure why that would be a bad thing, worse is having each module that
> supports foobar needs to have ap_hook_this_foobar and ap_hook_that_foobar
> to get itself to work right..

First of all, because the _hooks struct (declared by AP_HOOK_STRUCT) is a
static, I take it back.  It is not possible to share a hook between two
modules.

But why are multiple modules supporting foobar?  If your module needs the
same function that the core implements, don't duplicate the core's work,
take advantage of it.  Throw your function in as a REALLY_LAST function
and use what the other modules have already done.

What this really comes down to, is we need a real-world example of what
you are trying to do before we can even hope to help.  My problem is that
I don't really see what you are trying.  William Wrowe just responded
saying that a patch to allow some of what you are trying was shot
down.  It was shot down because nobody saw the need.

Apache takes a very hard line against just including function for the sake
of including function.  If there is a real need for an ability (the
ability to have a module declare it's own hooks, for example), the group
is perfectly willing to help implement it.  If it is just something that
sounds like it could be useful, then we don't in general implement
it.  Give a real-world example of what you want, and we can and will work
with you to make it happen.

Ryan

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




Mime
View raw message