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.
