Thanks for the explanation. The patch to eliminate install_transport_filters gets a +1 from me.
Bill > > > 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 > >
