httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: Adding new module callbacks.
Date Wed, 28 Jan 1998 19:35:36 GMT
On Wed, 28 Jan 1998, Ben Hyde wrote:

> This proposal arises out of Dean's recent frustrations
> with avoiding the stat calls, and Randy's suggestion
> to extend the module structure.  It's a pain that
> extending the module structure is so expensive.  What's
> in the module structure should only be what a module
> must define, not all those things that are optional.
> 
> If people like it, maybe somebody can volunteer to
> implement it.  This design would need a little sanding
> before the varnish is applied.

(I'll avoid my usual rant about how people should memorize all 40
megabytes (compressed) of new-httpd mail archives before they post
anything here. Be thankful)

This is a concept that has generally been accepted as part of the API
redesign for Apache 2.0. Once I get some free time and write up the ideas
that I've been collating, my ideas on this should become clear.

At any rate, yes, having modules register their functions using callbacks
is definitely in the stars for Apache. There are some other issues to be
considered, however, besides just simplification of the module structure:
Namely, one thing that we want is to reduce the chain of possible 
DECLINEDs that a module should go through before doing its thing. e.g., a
module that only serves data should (currently) check the method of ther
request, and return DECLINED if it's not GET. It should also set
r->allowed. However, many modules don't do this correctly. This can cause
Apache to behave incorrectly.

>From everyone's standpoint (the module author's, Apache's, etc...) the
easier thing to do is to register these sorts of things with Apache when
the callback is registered. This lets Apache decide when to call a module,
instead of the module having to worry about it.

Another issue is that of the "priority" (for lack of a better term) of
modules. Right now, each given phase has its available functions executed
in the reverse order of module configuration. This is often not the best
order. Modules should have some say, as they are loaded, or via user
configuration, over in what order they are to be executed.

Furthermore, the question of at which points a module can register a phase
has come up. Can a module only register callbacks at startup? Or can it
add it in the middle of a request, because it knows it will be needed
later? How does Apache handle this? Is it then added for all requests that
server is handling, from then on? Just for that request? Just that thread
(or whatever)?

Further questions, such as exactly which phases should be defined, and
which "options" are good for them to have, also need to be considered.

These, and other issues, have been discussed in the past WRT this issue,
and need to be addressed by any possible solution. It needs to be a
part of the general 2.0 API rewrite, I think, and shouldn't be pigeonholed
into 1.3. We decided that a long time ago.

There is also the issue of extensibility, and the ability to "clone" the
Apache API in other servers. This is a larger issue with the Apache API in
general, but there needs to be an easy way for servers to only support
some of the Apache request phases, and to allow modules to still run, and
gracefully degrade, on these servers. This is also true of, as we
discussed last month, backwards and forwards compatibility between
versions of Apache.

-- Alexei Kosut <akosut@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *



Mime
View raw message