httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: How to Handle Handlers and Order Hooks (and Other Matters)
Date Mon, 01 Jan 2001 14:20:09 GMT

> > I dislike calling every handler, even if we could tell before-hand that we
> > aren't going to use it.
> > 
> > Could the handlers register a hook with the following call:
> > 
> > ap_register_handler(char *handler, func *handler_func, pred, succ, order);
> > 
> > The core could then keep track of everything internally.  Allowing us to
> > use a simple table to determine which Handler should be called, but making
> > things look like hooks to Apache.
> I agree, but I believe that the ability for the core to prefilter hook
> functions is something that can be done for other hooks, too. So, if we
> are going to have this ability, we should have it across the board,
> rather than special-casing this particular one. Once you agree that,
> then you should agree that an acceptable interim solution is to _not_
> prefilter for now, but note that we should. Its an optimisation.

I agree that this might be useful for other hook functions.  I disagree
that this is just an optimization.  While it is an optimization, what
concerns me is that it has implications for the API.  I would prefer to
not have to change the way handlers work in the middle of the 2.0
series.  If we do change such a basic API, then we have lost all hope for
compatability.  If we do the original design with the idea in mind, then
we might be able to keep a single API throughout.  I agree this is harder,
but it is worth trying.

Did you see my comment about filters at the bottom?

> However, I'm now halfway through type-safe generic hooks (i.e. ones that
> modules can export but don't screw up if the module isn't there). I
> think I have a rather elegant solution to this, so I'm going to stick
> with it for now. I'll present it later today, I hope.

I look forward to seeing it.  BTW, I have the NULL pool hack completely
removed now, but I can't commit it.  As soon as I can, I'll see if this
solves our big memory leak on FreeBSD.  :-)


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

View raw message