[PATCH] Extended API (EAPI)

["Ralf S. Engelschall" <rs...@engelschall.com>]

Time has come...

Already five months ago I've started working on Apache API extensions I've
named EAPI. The goal was to fill the gap between what our current API provides
and what complex modules like mod_perl, mod_php, etc. actually need because of
the requirements from the user community. The stuff was recently finished when
I wrote the MM library for shared memory support (I posted a preview patch
when you remember). And now time has come to incorporate this projects results
into the Apache 1.3 main stream.

Because of the large time range EAPI was already extensively tested on really
a lot of Apache installations around the world and successfully survived
practice the last months. The code is stable, complete, clean and provides the
following major additions to Apache 1.3:

  o  Context Attachment Support for Data Structures
  o  Loosly-coupled Hook Interface for Inter-Module Communication
  o  Direct and Pool-based Shared Memory Support 
  o  Additional Apache Module Hooks

A lot of module authors (and indirectly this way their users) will benefit
from this extension. It's completely(!) encapsulated in #ifdef EAPI...#endif
containers and this way do not harm us in any way until the user enables it
with the EAPI configuration rule. And it should be provided in this
encapsulated form for Apache 1.3. For Apache 1.4 and 2.0 most of this stuff
can (and should) be moved into APR, of course.

Attached is the original EAPI tarball containing the source files and the
patch as stand-alone files (use this for better reviewing) and a large
all-in-one patch which applies EAPI to the current 1.3.7-dev CVS state (use
this for easier testing). Additionally I attached the MM library which is
optional but needed for the shared memory support.

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: [PATCH] Extended API (EAPI)

[Ben Hyde <bh...@pobox.com>]

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

Re: [PATCH] Extended API (EAPI)

[Mark J Cox <ma...@awe.com>]

> Attached is the original EAPI tarball containing the source files and the
> patch as stand-alone files (use this for better reviewing) and a large

FWIW we've been using EAPI here for some time and it works, it's stable,
and the source is very clean.  +1

Mark