> > 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...
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?
Bill
