Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 4 Dec 2012 18:04:39 +0100 (CET)
From: fabien@apache.org
To: APACHE development mailing list <dev@httpd.apache.org>
Subject: Re: 3 questions about inclusion of mod_macro into apache
In-Reply-To: <201212032301.57606.sf@sfritsch.de>
Message-ID: <alpine.DEB.2.02.1212041755410.25381@localhost6.localdomain6>
References: <alpine.DEB.2.02.1212031035110.3588@localhost6.localdomain6>
 <201212032301.57606.sf@sfritsch.de>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


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.