httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: 3 questions about inclusion of mod_macro into apache
Date Mon, 03 Dec 2012 22:01:57 GMT
Hi Fabien,

I haven't really looked at the source in detail, yet. So this is kind 
of a preliminary opinion.

On Monday 03 December 2012, Fabien wrote:
> 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.

If a module, then modules/core, IMHO.

>    "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*".

FWIW, we also have <IfVersion> in mod_version (which really should 
have been in the core, IMNSHO). I think Warning should go into core to 
complement Error. If there is no significant disadvantage to keeping 
<Macro> and Use in a module, then I would prefer that. But this is not 
a strong opinion.

> * 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.

I think the -c/-C command line handling does something similar (see 
arr_elts_getstr() and friends in server/config.c). If these can be 
merged with mod_macro's functions, then that would be nice.

> * 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.

Lazy initialization has the advantage of using less memory if no Macro 
is used. That's especially true if we put Macro into the core. But I 
will need to do some source reading before I have any informed opinion 
on this.

> 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".

We could also start with "MU" (which looks like less work initially) 
and then see how things work out. An advantage to a separate module is 
the separately configurable LogLevel. But as I don't use mod_macro, I 
don't know if that is important.

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

Yes. I think putting it into the default 'most' set would be ok. 
People who compile httpd with 'few' modules probably don't have any 
need for macros, either.

> *** 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?

Yes, seems useful and is small. Put it into core.

> *** 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.

I don't see any need for that. If there is a use case, then yes.


View raw message