Cliff Woolley wrote: > Noel and I had a little discussion just now on IRC about hook ordering and > the fact that in 2.0 we have made the admin's life a little harder by > hard-coding the ordering of certain modules (eg mod_dav vs mod_jk2). > > Basically the problem is that a completely automatic ordering is good for > the cases that have particular ordering constraints, but bad for the cases > where the ordering is underconstrained because the admin has no choice as > to which of the possible valid orderings is used. > > So we talked about two things in particular that would help: > > 1) A means to list all the hooks and which modules had hooked them in > which order (e.g., httpd --list-hooks) as a diagnostic. > > For this one, it looks like we might need a way to keep track at a > global scope what hooks there are. Right now, the only list of hooks is > static to the file the hooks were declared in (a static struct called > _hooks in that file). Or we could just only allow --list-hooks to list > certain hooks which are known to the core a priori.
I thought I had this in there already? Long time since I've looked, though. > 2) A means to restore some control to the admin. > > Noel suggests expanding the current APR_HOOK_FIRST/MIDDLE/LAST etc > scheme with some priority bits which could be set by the admin: > > We could have [CLASS|priority]. The current ones, APR_HOOK_FIRST etc, > are the CLASS. Admins could be given a HookPriority directive by which > they could add a priority for a given mod+method. So the class would be > the high-order bits and the priority would be the low-order bits, > basically. Thus if the admin doesn't use the HookPriority directive, > everything works as-is. But if they do, it just provides additional > control over list insertion. +1! They're already spaced apart somewhat, aren't they? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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
