httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: hooks
Date Wed, 21 Jun 2000 02:24:05 GMT

> Sorry for confusion, when I said it needs to include AP_* I really meant the
> stuff generated BY the AP_* macros :)
> Anyway.. you are right the ap_run_(hook_name) symbol must be exported so
> that the module can call it however..... ap_run_* uses _hooks, _hooks comes
> from AP_HOOK_STRUCT, which is static, which isn't exported to the module, I
> guess this is where my confusion comes from. I am very probably wrong - or
> misunderstand something about windows (or AIX) linker, but I certainly
> thought this was a no-no.

Nope, this is fine to do.  If we really want to, it would be very possible
to export the ap_run_* functions, and call them from anywhere.  In fact,
if you look at the Windows .def file, we explicitly export the
ap_run_pre_config for http_main.c.  This is done in some magical way that
I don't understand so that just http_main.c can use it (OtherBill, could
you clear this up?)

> This is definetly a good goal, however adding to the hooking that was in
> 1.3 so it had order fu in the API might have been a good thing, if for no
> other reason to ease migration from 1.3. As is obvious I've come along (to
> hacking on apache) late in the 2.0 time - so I may be missing key
> discussions, I will go to an archive and start perusing, but it seems the
> old API had some very good features (minus the ordering troubles)..

Adding to the 1.3 hooking would have been hard and ugly.  The current
implementation is relatively easy to understand and clean.  Also, as
somebody who has ported more than his fair share of standard modules, I
can say that the port is very straight forward and easy to do.

> I'm sorry - what I was referring to was suppose there was a foobar hook
> (ap_hook_foobar) and it is used by the core, then I write a module and I
> want to go behind the core's back (for some reason) and trigger a foobar
> (ap_run_foobar) too, to do this I would either
> a) have to hack up something (as you said big hack above) to do this, but
>    supposedly it's "bad"
> b) have a new hook, and any module that wants to do foobar for my protocol,
>    or http would have to know about both and be sure to hook both.


  c) Change the linkage for ap_run_foobar, so that anybody can run
     it.  This is not impossible to do, we just haven't had a request for
     it yet with a valid reason behind it.  What I assumed you wanted to
     do was have the core implement ap_run_foobar, and mod_baz implement
     ap_run_baz, and everytime a module registered for foobar, it
     automagically registered for baz.  That requires a hack.  Letting
     mod_baz call mod_foobar requires a good case for it to be made, and
     the linkage to be changed.  I do not see this as an insurmountable
     issue at all.

> I'm looking at it more from a standpoint of "Why are we limiting it in this
> way?", it is also reasonable to decide these limitations are acceptable -
> the original questions where asked while I was still in throught process,
> explanation below (1)...

We are limiting this way because it is an easy place to draw the
line.  Prove that the line should be moved, and it will be.  :-)

> (1) Ok real world has to do with....
> I was doing some thinking about protocol modules. I was thinking the http
> stuff could be split into a separate module, and we can have a generic
> server framework (as most of the work is really there and this would just
> be tying up loose ends). I was thinking about the next protocol modules
> that might come along, and thought there were a bunch of useful modules for
> the http side of things, perhaps new protocol will have a use for
> them. Then it started to occur to me the hooking mechanisms probably aren't
> going to be sufficient for inter-module hook relay, to boot it wouldn't
> really provide new protocols with a way to use hooks that exist for http
> things.

Actually, a lot of this work has been done.  Mod_echo is a good example of
a protocol module that does work with the current server.  Somebody else
on the list has recently been posting that he too has written his own
protocol module.  I can't remember right now what protocol it was.  I
suspect that the multi-protocol stuff will change drastically at some
point in the future.  I have been toying with the idea of writing a
compiler server (I'm a sick man).  The compiler server would take C code
and return a binary for whatever platform you asked for (using
cross-compiling).  So, the server framework idea has some people who want
to make it work.  I also know that right now, I am working far too many
hours on Apache 2.0, and I am unlikely to work on the framework side until
2.0 is released.  I expect many others feel the same way, because we want
to see 2.0 a reality soon.

> All of this is fine if the abstraction of protocols is to give an easy way
> of plugging in an all new monolithic module that incorporates all the stuff
> for another protocol (ala the apache core stuff). If it is there to provide
> the ability to have a very generic framework and I can easily plug in
> different protocols and those different protocol modules can use some
> common modules to do certain aspects then it seems what exists isn't going
> to work well.

I think it will work just fine once we change some linkages.  I really
don't think this is a big issue.  If it is, we just fix it for 2.1 or
3.0.  But, I also think throwing away a very good hook mechanism because
it isn't perfect yet is a bit much.  Take a look at the ap_run_pre_config
and ap_run_open_logs stuff, and tell me if that is close to what you want
to do.

> I understand 2.0 might not have all that in it, but since 2.0 is new enough
> not to have all modules ported to it, I figured it may be worthwhile coming
> up with something (the more I look at it the more the 1.3 hooking facility
> seems to be it) to correct these hooking issues.

I think you would be surprised how many modules have been ported to 2.0
already.  The 1.3 hooking facility has some major drawbacks beyond just
the ordering.  Whenever a new hook is added (much more likely with more
protocol modules) every module needs to be re-compiled and possibly
modified.  This is a big hit for some people.  Some people don't have the
time/desire to keep up with Apache development.  Some companies have
modules that are not released as source.  The new hook mechanism allows
Apache 2.0 to not have to bump the MMN whenever a new hook is added.  I
suggest playing with it a bit more.  I think you will find that it can do
everything you want it to, it just needs a littel carressing and fine


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message