httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: hooks
Date Tue, 20 Jun 2000 22:18:29 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.

> is some good reason this has been done, but more than once I've needed to
> remind myself what the macro generated (ick) functions were going to look
> like, seems if we had a single function that dispatched these hooks it
> would be easier to maintain/lookup.

The macro generated functions are ugly, but IMHO they are better than use
having to duplicate code over and over again to do the same basic thing
with different parameters.

> It would also seem to be a good design to have _dynamic_ modules use
> runtime lookups of these hooks, rather than _static_ information. Doing
> this would remove some dependency of a dynamic module on the apache it's
> being used with.

I am very confused about what you are asking here, but I'll try to answer
anyway.  :-)

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?  

> The DECLARE_HOOK stuff is good, however it doesn't lend itself well to
> having modules (protocol modules?) ap_run_*()'ing hooks (ie I must see an
> AP_DECLARE_HOOK for fudge, before I can actually bind to it). It also means
> I can't really "reuse" a hook if I come along with a module to replace the
> old functionality...

A protocol module should not be trying to ap_run_*() the hooks.  Each
protocol module will need to implement it's own set of hooks.  The
protocol module needs to know about the hooks it is allowing modules to
implement.

What do you mean you want to "reuse" a hook if you come along with a
module to replace the old functionality.  I assume that since you are
working on the proxy, this is a proxy question.  It would help a lot if
you could explain exactly what you want to do.
  
Are you saying you want to basically replace a hook that the server
implements with one the proxy implements?  You can't do that.

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.

Ryan


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


Mime
View raw message