httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Apache config
Date Fri, 30 Apr 2004 03:52:00 GMT
At 08:21 PM 4/29/2004, C.J. Collier wrote:
>This project made me think that perhaps Apache should be able to read/write config files
that aren't so difficult to parse.

:)  Many of us agree...

>Of course, the first example of an easy-to-parse config file format was XML.  But I realize
that this will not work, since backwards compatibility is important.

Hmmm.  Backwards compatibility has it's strong points and most
definate weaknesses.  Even in the current 1.3->2.0 transition, we
made the double-quoted arguments for the ErrorDocument directive
make a bit more sense in 2.0.  Please don't assume that because
httpd "has always done it that way" we aren't open to considering
other options.

XML parsable config files are on many, many admins and developers
minds.  Provided there is support for the old format, don't be surprised
if someone comes up with XML flavor config files for 2.2 :)

>If we want to be able to read easier-to-parse config files and we want to keep our backward
compatibility, it seems to me that we should write a modular config file parser.    I could
go into implementation, but that's no fun right yet.  Plus, if folks think that it's a good
idea, I'm sure I'll spend plenty of time doing just that :)  I would expect to learn something
from my frustration, too.  I wouldn't expect the config module to only read XML and the current
format; I would expect the config module to be pluggable, so that we don't have this problem
in the future.

I know of some Java code that could be made available, and there
is also perl and tcl code IIRC.  However the best parser is httpd itself,
and now that Apache 2.0 reads into a config tree, spitting it out should
not be the problem it was back in 1.3.

>What I want to know is this:  Does this list feel that it is a worthwhile use of my time
and the time of the devs to spec out, implement, debug and integrate a means of reading arbitrary
config data?  I realize that it would be a great deal of work, but I can see a great deal
of benefit that would come from it as well.

I would love to see this effort, if only the code is common to httpd itself.
Why have two different parsing schemas, one for httpd, one for another
arbitrary utility lib, only to have each mis-recognize the other's files?

You are on the right track - I only suggest you look at httpd itself for
1/2 your answer :)


View raw message