Date: Mon, 4 Aug 1997 11:10:19 -0700 (PDT)
From: Alexei Kosut <akosut@organic.com>
To: new-httpd@apache.org
Subject: Re: apache handlers (1)
In-Reply-To: <Pine.GSO.3.95q.970804133309.16348A-500000@csa>
Message-ID: <Pine.GSO.3.95.970804110411.4186A-100000@veal.organic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Mon, 4 Aug 1997, Stanley Gambarin wrote:

> 	In its current state, modules are required to provide a module 
> structure, which lists any handlers in the current module that should be
> invoked by the server during various phases of the request processing, i.e
> access_checker, logger, etc.  This approach (using a structure) provides a
> very inflexible solution, where an addition of an extra stage to request
> processing requires change to all modules, subsequently causing lost of
> backward compatibility of the old modules.  This idea popped up after 2 
> huge diffs which added child_init, child_die stages to modules, and I am
> not even mentioning any external modules.
> 	The new idea is to allow modules to register the stages of the 
> execution they would be interested in, instead of module specifying it in
> the module structure.  This would provide the following advantages:
> 	- module is only called when it is interested in a stage, i.e
> 	module has registered a handler.
> 	- BACKWARD COMPATIBLE: addition of the new stages to execution
> does NOT break any existing modules, as they do not care about new stages
> and only new modules would need to register them, thus limiting the change
> only to the core.
> 	- allow for dynamic [un]registration of the module handlers during 
> runtime.  This can be useful for dynamically [un]loaded modules, as well
> as subrequest mechanism, where i need to find a type of a file, why do i
> have to invoke method to check_user_id, so this should provide a boost
> (well, ok a bump) in performance.

Several things:

1. This is not a new idea. I suggested it several months ago, and it is
   part of the plan for 2.0 (which is held completely in the mind of a
   couple developers. Just try and get at it! Hahahahaha!)

2. Adding additional phases to the module record is backwards compatible
   (it's not forwards compatible, but that's another matter). ANSI C is
   smart enought to fill in the extra slots without complaining.

3. Your patch is reversed.

4. As near as I can tell, your patch does not provide the equivilent of
   Dean's optimizations to eliminate NULL handlers.

5. It does not provide a graceful mechanism for adding new phases to the
   API, either. It would require new functions to be added for each of
   those. IMHO, it's better to have a single callback register function
   of which one argument is an enumeration (or set of #defines) that
   specifies which phase you are registering for. This allows modules to
   be compatible with older versions of Apache (see my earlier email on
   specifies of this. I don't feel like going over it again right now).

6. As Roy has repeatedly pointed out, if we do this, there are better
   things we can do: Currently, handlers are only registered by content
   type. It would be very handy if they were also registered by method,
   and possibly other things. We'd need to sit down and either think of
   all these things (unlikely), or set up the callback functions to be
   extensible (more likely).

At any rate, this is a defenite 2.0 thing. Let me say that again: I want
to see something like this very much (and I have plans to write it
myself, if neccessary), but I do not want to see it in 1.3. Because we
need more time to do it right, and AFAIK, we have a 1.3 beta planned in
ten days.

-- Alexei Kosut <akosut@organic.com>