httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Thoughts on a 2.0 API
Date Tue, 10 Jun 1997 00:52:24 GMT
On Tue, 10 Jun 1997, Rob Hartill wrote:

> So, what I think it's better to throw out the concept of named phases.
> By all means start from the ordered phases we have and propose, but
> don't enforce that order on everyone implicitly or explicitly. I should
> be allowed to juggle any of the core handlers around to achieve my
> objectives without feeling guilty about it.

Hmm. I disagree. There needs to be named phases, becuase a request is
linear, and things happen: connection open, request read, response
sent, connection closed. Within those four general areas, things
happen - again in certain orders. 

So while I think it might be useful to get rid of "named phases" in
the sense of "this phase is for determining the media type of the
document", it is not useful in the sense of "this phase occurs after
the request has been read, but before the response headers have been

In addition, I'm a bit scared of all this talk about expanded
configuration. While I support it, I don't want to turn Apache's
config into, where details on how to run the protocol part
of the server are configurable by neccessity. In other words, most
people just modify the first few lines of their and let it
run. But if you want to do anything special, you have to understand
the rest, and be able to modify it (I know I'm oversimplifying
here). I want the user to continue to be able to add complex
functionality *without* having to know anything about how the request
works, and ordering of API phases, and whatever else.

I think the API may *need* named phases, even though two paragraphs
ago I said they didn't. For example, in order for more than one
authentication module to worth correctly, they all need to follow a
similar approach. Which they do now, in the current API. With Rob's
approach, they might not.

I see two different uses for the API: Firstly, when writing your own
custom server, and you have control over all your modules, and know
exactly how they all work, and how you want to deal with them. The
other approach is the one I've been talking about lately, the
"plug-in" theory, where a server admin can take the server, and add in
modules written by others that perform certain functions, and it all
works seamlessly, without any configuration. In other words, I
download a binary of the server, drop precompiled object files for
PHP, mod_perl and a log file analyzer I bought from a mail order
catalog into a "modules" directory, and the server just does it with
mininal input from me.

The API I proposed works very well (IMHO) in supporting this second
theory of server use, but not as well with the first. Ben and Rob's
ideas probably work better with the first use, but not the second. We
need to work out how to make both work in Apache 2.0.

Alexei Kosut <>      The Apache HTTP Server

View raw message