httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: [PATCH] Extended API (EAPI)
Date Tue, 27 Apr 1999 15:06:35 GMT

EAPI -> +1.

I too wish it was somewhat broken into more bite sized peices which we
could chew up before swallowing - if only to torture Ralf.

I'd love to see this go in as soon as possible.

Let me chew on the hook scheme for a few paragraphs.

I like it enough that I would prefer that it not be optional.  Rather
I'd like to see us using it to try to advance the 1.* family API.

My problem with promoting it to being a first class part of the the
API is that I can't quite stomach the design as it stands.

We need to make a general ap_hook_* facility with the intent of making
the module API more plyable.

I'd very much like to move toward a hook registry model that can
replace the brittle set of method slots found in the module structure.

Then when new hooks are added in the core it wouldn't be such
a big rock tossed into a small pond.

Instead modules could hook up in their init function.  In time the
module structure might even wither into a vistigal organ.

Note that we already "compile" the methods out of the module structure
and into something more efficent (e.g.  build_method_shortcuts in
http_config.c).  I have trouble distinguishing the problem all that is
trying to solve from the one that Ralf needed to solve.

The run_all flag to run_method could easily be folded into Ralf's
ap_hook_sig.  We might even - heaven forbid - provide variations of
ap_hook_sig that support an error protocol.

I'm sad that the method keys are strings, rather than symbols or
atoms.  We really do need atoms, back filling their use into the
current API is an amusing mess.

 - ben

View raw message