httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] Remove the insert_transport_filters hook
Date Tue, 05 Feb 2002 22:03:15 GMT
Thanks for the explanation. The patch to eliminate install_transport_filters gets a +1
from me.

Bill

>
> > From: Bill Stoddard [mailto:bill@wstoddard.com]
> > Sent: Tuesday, February 05, 2002 1:44 PM
> > To: dev@httpd.apache.org
> > 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
>
>


Mime
View raw message