httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Marmor <mar...@netmask.it>
Subject Re: Apache config
Date Fri, 30 Apr 2004 10:42:09 GMT
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
marmor@netmask.it
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

Mime
View raw message