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 13:28:17 GMT

I wanted the day to think about this.  :-)

I almost like it.  My only concern, is the matching.  If I understand what
you are saying, each handler would register a function, without specifying
the char *, then the core would call every handler, and pass them the
(Handler, Mime-Type, etc).  The handler would then either return quickly
with a DECLINED, or it would try to process the request.  Is that correct?

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.


On Mon, 1 Jan 2001, Ben Laurie wrote:

> Stunned you into silence, eh? I need some feedback one way or the other.
> Or should I just do it and await the screams?
> Cheers,
> Ben.
> Ben Laurie wrote:
> > 
> > OK, so the obvious thing is that handlers should be sorted like hooks. I
> > initially thought that they should also be sorted according to their
> > wildness but the more I think about it, the more I think that the whole
> > handler structure should disappear and be replaced by YAH (Yet Another
> > Hook). The down side of this is a slight loss of efficiency. The upside
> > is that handlers can be more subtle about how they match the content
> > type/handler string (and other things they may want to match), when they
> > match it, and how they interact with other handlers.
> > 
> > You could argue that they could still do this with an extension of the
> > current system (i.e. string matching as a prefilter before calling the
> > handler, which then can be more subtle if desired). Yes, this is true,
> > but the same must surely be true of all sorts of other hooks, so why
> > single this one out? Also, it reduces the clarity of the process and
> > potentially makes handlers do silly things (like match "*" because they
> > really want to match something completely different) in order to squeeze
> > into the structure.
> > 
> > So, what I'm inclined to think is that if we want to use "hints" to
> > prefilter hook calls, we should do it in general, not just for handlers.
> > 
> > With that out of the way, I'd propose to axe the handler structure, and
> > introduce a new handler_hook, which would look like this:
> > 
> > int handler_hook(const char *handler, request_rec *r);
> > 
> > where handler is the thing currently matched against the string (i.e.
> > the handler set by SetHandler and friends, or the MIME type). It can
> > return DECLINED, OK or an error. Anything except DECLINED will stop
> > processing. Obviously, the first thing most handlers will do is a string
> > comparison against handler...
> > 
> > OK, next is the question of configured control of ordering.
> > 
> > This one is potentially really easy. We just leverage the existing
> > {prede,suc)cessor arguments in the hooking calls. What we do is allow
> > the config file to specify ordering between pairs of modules for a
> > particular hook, something akin to:
> > 
> > HookOrder handler mod_dir mod_autoindex
> > 
> > which would cause mod_dir's handler hook to run before mod_autoindex'.
> > There are two issues, one new, one not new. The first is naming - we
> > _really_ should have a global namespace for modules. Its time to stop
> > avoiding this question! I propose we use something akin to Java -
> > derived from DNS. I see no need to use backwards DNS, though. My initial
> > thought is that global module names would look like this:
> > "<FQDN>/<localname>". So, mod_autoindex would be
> > "", for example. Mod_backhand would be
> > "" (say). Then the HookOrder directive would look
> > like:
> > 
> > HookOrder handler
> > 
> > (if people object the URL-ish look, we could use "-" instead of "/",
> > which makes it clear we're doing something totally different). Oh, I'd
> > include the module name somewhere in the module structure, so we can
> > enumerate them, BTW.
> > 
> > OK, the other issue is this - should we introduce the concept of
> > mandatory and overridable {prede,suc}cessors? The idea being that
> > overridable ones can be overridden by config (but specify the "usually
> > appropriate" order), but mandatory ones can't? Or should we say that if
> > they are what we'd consider overridable, then they MUST be configured. I
> > don't hugely like the second option, because I firmly believe that you
> > should be able to run Apache with an almost empty configuration. And,
> > that it should be as obvious as possible what needs configuring when it
> > does.
> > 
> > Oh, BTW, if we do this, we get I/O filtering ordering for free. Cool, or
> > what?

Almost, but not really.  We still need to figure out how to specify a
filter for use in a request (I have the logic figured out, but I haven't
written the code yet).  We also don't really use the standard hooks
mechanism for the filters at all, so this probably won't help much in that


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

View raw message