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. 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. --Cliff
