httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabien <fab...@apache.org>
Subject 3 questions about inclusion of mod_macro into apache
Date Mon, 03 Dec 2012 09:38:18 GMT

Dear httpd devs,

Mod_macro has been accepted for inclusion into Apache HTTP Server, and
my commit access has been extended to "httpd". I should do it when I have
time and I'm given the go ahead, hopefully within the month.

Some preliminary questions before doing anything.

The current module directives are:
  - <Macro + Use directives to define & use a macro
  - Error directive, now redundant as one has been added since 2.3.9
  - Warning directive, similar to error but which does not stop

Macros are kept in a temporary memory pool and can only be used at
configuration time. They cannot be defined and/or used within a
.htaccess file for instance. This is a feature.


*** Question 1: there are several possible strategies to include the module

* option "module" vs "core"

   "module" - add the module more or less "as is" after some cleanup, for
instance under "modules/core", or under a new "modules/macro" directory.

   "core" - incorporate the module in core (mostly "server/core.c").
I'm not sure how Apache core is used, and whether such features should or
should not be included. From a language perspective, it makes sense to have
macros there, together with preprocessor-like configuration stuff such as
"*Define" "<If*" "<Else*" "Error" "Include*".

* option "util": Move/merge string array processing stuff into "server/util.c".
This is used when expanding a macro, and could be useful to someone else.

* option "config": ideally, macros would require "pre/post read config" hooks
which do not exist. The existing pre/post config are executed after the file
has been read, and this is too late. Adding such a hook would avoid a lazy
initialization, but maybe adding a hook just for such a limited benefit is
not really worth it. Directive "Define" handling also uses a lazy
initialization to deal with the very same issue.

It seems to me that the possible choices are:
  - M   "module"
  - MU  "module+util"
  - MUC "module+util+config"
  - C   "core"
  - CU  "core+util"
  - CUC "core+util+config"

I am in favor of choosing "CU", or at default "MU".

If this is kept outside core (choices M*), I think that it should nevertheless
be included in the default compilation and installation.


*** Question 2: obviously, I'll remove the Error directive which is now
provided in core. However, should I keep the Warning directive, possibly added
to core independently of what is done with the macro stuff?


*** Question 3: would it make sense to add the ability to remove a macro? I'm
not sure that it is useful, as a macro can be overwritten, but it would look
more complete that way. That could be "UndefMacro xxx" or something similar.


-- 
Fabien

Mime
View raw message