Return-Path: 
 <new-httpd-return-3462-apmail-new-httpd-archive=apache.org@apache.org>
Delivered-To: apmail-new-httpd-archive@apache.org
Received: (qmail 6541 invoked by uid 500); 9 May 2000 03:49:19 -0000
Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: new-httpd@apache.org
list-help: <mailto:new-httpd-help@apache.org>
list-unsubscribe: <mailto:new-httpd-unsubscribe@apache.org>
list-post: <mailto:new-httpd@apache.org>
Delivered-To: mailing list new-httpd@apache.org
Received: (qmail 6528 invoked from network); 9 May 2000 03:49:19 -0000
X-Authentication-Warning: fnord.io.com: manojk set sender to manojk@io.com
 using -f
Date: Mon, 8 May 2000 22:49:19 -0500
From: Manoj Kasichainula <manojk@io.com>
To: new-httpd@apache.org
Subject: Re: <Perl> vs. external config
Message-ID: <20000508224919.A20306@io.com>
Mail-Followup-To: new-httpd@apache.org
References: <20000426200524.A3812@io.com>
 <Pine.LNX.4.10.10004261824320.392-100000@mojo.covalent.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.14-current-20000508i
In-Reply-To: <Pine.LNX.4.10.10004261824320.392-100000@mojo.covalent.net>;
 from dougm@covalent.net on Wed, Apr 26, 2000 at 06:30:15PM -0700
X-UID: 2
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

On Wed, Apr 26, 2000 at 06:30:15PM -0700, Doug MacEachern wrote:
> sure, but i have not been convinced the new way is better.

Fair enough. Then backward-compatibility isn't the issue.

> i don't see what the problem is with keeping the option open, so why take
> it away?

Well, if support for it doesn't change the config parser in any way
(and Ryan assured me over beer that it doesn't), then I guess it's not
a big deal. I'm basically reacting to the idea that we should actually
add code to support modules like mod_macro, and perhaps mod_perl's
configuration functions, if the work can be done just as well
externally.

<speech length=long>
There are numerous features that all servers that have configuration
files could use, such as being able to:

- include other files
- support macros
- support conditional evaluation
- get configuration from a db
- get configuration from an LDAP directory
- get configuration from ...
- generate configuration in Perl
- generate configuration in Python
- generate configuration in ...

If you have m such features, and n servers, the world has to expend
O(n*m) effort to add these features to every server. Wouldn't it be
nice if these features were included in separate tools, so that they'd
only be implemented O(m) times? You'd also require far less security
auditing and bug fixing, and people writing new servers (or any other
programs for that matter) could spend more time working on their own
specialized code, rather than solving problems that have already been
solved dozens of times in the past. And smaller pieces are easier to
maintain anyway. This is the goal of OO, but pulled out to the
tool level.

This is why I am strongly encouraging as much separation of features
into external commands as is possible without sacrificing genuinely
useful function.

</speech>