3 questions about inclusion of mod_macro into apache

[Fabien <fa...@apache.org>]

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

Re: 3 questions about inclusion of mod_macro into apache

[Nick Gearls <ni...@gmail.com>]

On 04-12-2012 18:04, fabien@apache.org wrote:
> Without UndefMacro, it can lead to warnings on redefinitions that 
> could be considered noisy and could not be removed.
I agree

Re: 3 questions about inclusion of mod_macro into apache

[Jim Jagielski <ji...@jaguNET.com>]

Yeah, sf's answers pretty much // mine.

On Dec 4, 2012, at 12:04 PM, fabien@apache.org wrote:

> 
> Dear Stephan,
> 
> Thank you for your answer.
> 

Re: 3 questions about inclusion of mod_macro into apache

[fa...@apache.org]

Dear Stephan,

Thank you for your answer.

If anyone want to look at the latest source, tell me and I'll make the 
current "dev" version available. I've switched to using a hash table 
instead of an array to store macros, and I have started cleaning up the 
code to remove traces which dated from apache 1.3 and seem not to be 
required anymore.

> If a module, then modules/core, IMHO.

Ok.

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

Yes, that is basically what I had in mind, but I have to check the 
fine details before merging anything.

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

Yep. The memory is really a hash table in a temporary pool.

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

I do not think that it is important.

> [...] Warning directive.
> Yes, seems useful and is small. Put it into core.

Sounds reasonnable.

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

I do not really have a use case, but users have more imagination than me. 
Without UndefMacro, it can lead to warnings on redefinitions that could 
be considered noisy and could not be removed.

-- 
Fabien.

Re: 3 questions about inclusion of mod_macro into apache

[Stefan Fritsch <sf...@sfritsch.de>]

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.

Cheers,
Stefan