> From: Bill Stoddard [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 05, 2002 1:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] Remove the insert_transport_filters hook > > > > This approach has an aesthetic problem that annoys me. If mod_yadda > > wants > > > to insert its > > > own replacement of CORE_IN and CORE_OUT, how does it reliable do so > > and > > > ensure: > > > > > > 1. CORE_IN and CORE_OUT are not also installed (their presence in the > > > filter chain when > > > they are not used is not right IMHO). > > > 2. That YADDA_IN and YADDA_OUT are installed at the appropriate place > > (ie, > > > they are not > > > installed above the NET_TIME filter for instance). > > > > The onus is on mod_yadda to make sure that things happen at the right > > time. This means that mod_yadda would register a pre_connection hook, > > most likely with the following arguments: > > > > ap_register_pre_connection(yadda_pre_conn, {"core.c", NULL}, NULL, > > APR_HOOK_REALLY_LAST); > > The core_pre_conn hook is declared APR_HOOK_REALLY_LAST. So which of the > two 'REALLY_LAST' > hooks (core_pre_conn or yadda_pre_conn) is really last? :-) > > If the answer is completely unrelated to order of config directives (or > unrelated to > configuration directives in general) then I am a bit happier with > eliminating the > install_transport_filter hook. However...
This depends on how the hook is registered, just like the rest of our hooks. The second and third arguments to all of the ap_register_* functions define predecessors and successors. That's why the second argument up there specifically states that the "core.c" hook needs to run after us (I may be wrong about that, it might need to be the third argument, but the idea is correct). Take a look at how mod_mime and mod_mime_magic work. The code defines the order, not the config file. > If the answer is 'it depends', then I am still leaning toward keeping the > install_transport_filters hook. We are unlikely to have many modules that > need to hook > install_transport_filters. That fact translates into fewer opportunities > for third party > modules or configuration directives to declare themselves 'REALLY_LAST' > and hose up > everything accidently. Does that make sense? Not really. The whole point of the hook code is that module authors have a lot of control over the order that the hooks are called. I am asking that we make modules that want to install transport filters use that control that we have provided. Ryan
