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 :) Bill
