C.J. Collier wrote: > I'm new to the list so please forgive my ignorance. I've had an idea > for a few years (I'm sorry for waiting so long to voice it) involving > the configuration of Apache. I tried to write an apache config file > reader/writer in Perl a year and a half ago or so, and it went poorly. > This project made me think that perhaps Apache should be able to > read/write config files that aren't so difficult to parse. > > 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.
Like Bill, I want to express my "+1" too ;-) I think that this effort can be done smoothly and without breaking backward compatibility; of course, old modules that will not be patched to fit the new model, will not enjoy its benefits, but will continue to do what they have done so far. The backward compatibility (source- level, not binary level) allows it to be done in 2.1 without watiting for 2.2. Let me quote something that I wrote to a friend: <LOOOOOONG TEXT> I want to suggest an alternative for command_rec. Old modules, at least for some time, will be able to continue to use the old-and-good command_rec, but new ones will have the option to use the new structure. A directive which is handled by the new mechanism, will be defined by 3 resources: 1. its definition in the XML files of the documentation. 2. the replacement of the command_rec. 3. the module code. However, contrary to the past, when most of the work was done in (3), I want to move as many as possible definitions to (2), and possibly to add things to (1). Many things that now are done by code of modules, can be done in the "new" config.c. The "new" command_rec will also have fields with details about how the value of the directive is stored (offset, size, type) like the genious and brilliant design of Xt (X Toolkit Intrinsics). The core will have access to all the directives that are defined in this way, without having any pre-knowledge about the module. Then it will be possible to write a module that will give external agent an exact picture of the current values of directives (of course with the obvious hierarchy of directories/locations/vhosts/etc.). Of course, modules which still use the old mechanism will not enjoy this feature. Changing a directive on-the-fly will not require parsing httpd.conf + a graceful restart, but only accessing the value of the directive. An external agent will just send a request (with the right authentication/ authorization) to the above module. Then, if the user of that agent (for exmple a user of a configuration GUI) will want to save it, the agent will request the current tree of directives and write it to the disk. In order to allow automatic generation of configuration files, a new format must be defined (probably XML-based), that will be more friendly for computer-programs (such as configuration GUIs). Of course, it must be friendly for humans too, because after your GUI procuded it, you can't use your httpd.conf anymore. It will be easy to write a tool to convert httpd.conf files to this new format, so it will be transparent for existing users. Advantages (if you are impatient, you may start with #5, and then return to #1): 1. New modules will be much shorter to write. 2. Ability to retrieve current directives (like editres in Xt). 3. Ability to change any directive, from anywhere in Apache, on-the- fly. 4. Ability to write REAL configuration-GUIs; Existing GUIs are so bad so nobody understands what's good with GUI (and I agree with them. with the current model of directive configuration in Apache, it is impossible to develop a GUI which is not awful). 5. The coolest feature (and probably most important): configuration GUIs will not have to learn all the directives/modules/syntaxes/ features/limitations/etc. of all the directives. All of this data can be obtained automatically from the combination of the "new" command_rec and the XMLs of the DOC (which will be read by the "new" config.c into empty fields in the "new" command_rec). Moreover, these GUIs will have automatic support for new modules, future directives, etc., without having to add anything to them. Believe me, I already experienced it with Xt, and it is really revolutionary! I used the special and modular structure of Xt to develop my own GUI Builder. It extracted all the data it needed from libXt, and I didn't have to feed it anything about the types, sizes, etc. of the various resources. It supported custom widgets without having to teach it anything about them. It even allowed its users to change EXISTING applications, that were not developed using my tool, even without any source code! (I used it to localize many binary applications, such as Netscape and Oracle). You could even add new menus, dialogs, screens, etc. to closed apps. And although the documentation of Motif/Xaw was not written in XML, I used it to learn more about each resource (for example, when the user asked for context-sensitive-help about a specific resource, its doc was displayed automatically). 6. Save anomaly and double configurations (for example, no need to configure things twice - in the DOC and in the module). 7. Elegance. </LOOOOOONG TEXT> -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __________________________________________________________ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
