> -----Original Message-----
> From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 1:07 PM
> To: [EMAIL PROTECTED]; [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);
This would guarantee that yadda_pre_conn function is called as one of
the last hooks in the server, but it is also guaranteed to be called
before core_pre_connection. If the yadda_pre_conn function returns DONE
once it installs its filters, the core_pre_connection function will
never be called, which handles case 1 above. Case 2 above is handled
because the yadda module is one of the last modules to have that hook
run, so they are guaranteed to be inserted in the same spot as the
CORE/CORE_IN filters would have been inserted has the
core_pre_connection function been run.
Essentially, because only one set of bottom-most input/output filters
will ever be installed, as long as they are installed by the last
function run by pre_connecton everything works correctly. We make sure
they are installed by the last function, because that function returns
DONE, which has existed in Apache forever, and is meant to be used for
this sort of thing.
> I assume returning DONE terminates the hook running with a RUN_ALL
hook?
> That seems non intuitive to me.
Yep, DONE terminates the hook. It may be non-intuitive, but the same
thing works on 1.3, and it is an important feature. I would suggest
that the RUN_ALL macros are really RUN_MOST, because they really mean
that all of the hooks should be run until one of them returns something
other than OK or DECLINED. This means that a RUN_ALL hook is terminated
early by any module that returns an error, or any module that decides it
is the last function to run for this hook.
> It seems to me that the install_transport filters provides some
semantic
> clarity, but I
> can be swayed either way right now.
My fear is that we are adding a lot of hooks that aren't well defined.
Because we are adding so many hooks, there are very few people who
actually understand how to use them all correctly. That just leads to
adding more hooks, because we don't really understand the ones we have.
I am trying to document the hooks we have and remove the ones we don't
need.
This is an important issue for me, because a few days ago I got bit by
the map_to_storage hook. I thought it did one thing, and it does
something completely different. If one of the developers who has been
watching every commit since the beginning of 2.0 can't keep track of all
of the hooks we have, how can we expect module authors who have lives
outside of Apache 2.0? :-)
Ryan
