rbb@covalent.net wrote: > The second problem is a bit different. One module implements a function > that another module uses. This is the problem we are talking about > here. In this case, mod_include implements ap_register_include_handler, > and mod_cgi(d) needs to use this function. Of course, one can bend generic hooks (that was a really stupid name choice, btw) to do this: mod_cgi(d) creates a hook that mod_include registers for. But this would be somewhat weird. So, moving on, I presume that there's a desire to avoid using the standard dl stuff to do this (i.e. dlsym()) - why? Shouldn't APR provide a facility to call (or not, as the case may be) a dynamically loaded function? Or is this something that tends to not be portable? If so, then I'd propose we do something just like generic hooks, only the "other way round" - mod_include declares ap_register_include_handler(), registers it with the core, which allows it to be called by name (or resolved by name) when present, and use the same kind of casting trick I used for generic hooks to render it typesafe. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff