httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: <Perl> vs. external config
Date Tue, 09 May 2000 03:49:19 GMT
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

<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.


View raw message