Using extensively mod_define, mod_macro and rewrite maps in very big
environments, I personally chose for ~{...} to be safe.
But, as far as we can change it, everyone can choose what they want.
Regards,
Nick
-------- Original Message --------
Subject: Re: Allow to set config variables in the config a.k.a. mod_define
Date: Thu, 20 Jan 2011 16:29:43 +0100
From: Rainer Jung <rainer.j...@kippdata.de>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
On 20.01.2011 16:02, Stefan Fritsch wrote:
On Thu, 20 Jan 2011, Nick Gearls wrote:
Using the $ character can interact with core interpolation, but also
with, for instance, mod_macro.
I strongly recommend to let mod_define's ability to replace the special
characters.
Moreover, mod_define is very stable, so why to strip it instead of
just extending it?
Sorry, I didn't make that clear in my original mail. It's very difficult
for a module to hook into the config processing early enough to be able
to override core's envvar interpolation. It's much easier to do that if
the functionality is in the core.
But conflicts with mod_macro and RewriteMaps are a valid concern. I will
try to include the ability to replace the special characters.
Do we want to change the default special chars? There are not many
reasonable combinations left that would not produce other clashes. Maybe
$( ) would be a possiblity.
If we stick strictly to ${XXX} then I don't see an immediate problem
with mod_macro, which should use plain $XXX. The syntax overlap with
rewrite maps should go away if variable names are not allowed to contain
a colon.
If this is correct, at least I would prefer sticking to ${XXX} and not
$(XXX).
Regards,
Rainer
-------- Original Message --------
Subject: Allow to set config variables in the config a.k.a. mod_define
Date: Thu, 20 Jan 2011 12:01:19 +0100 (CET)
From: Stefan Fritsch <s...@sfritsch.de>
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
Hi,
mod_define's capability to define variables in the config is a really
nice
to have feature and I have intended to integrate the module it into
trunk.
But I have now noticed that core's environment interpolation of ${xxx} is
done before mod_define runs, and that it is not possible to override the
values of os envvars with mod_define. Therefore I now intend to integrate
a reduced variant of mod_define into core's ap_resolve_env. This also
makes it possible to add a command line option to define a variable.
I don't intend to include mod_define's ability to replace the special
characters ${...} with other characters. I don't think that is worth the
effort. Core will interpolate envvars with this syntax anyway.
Anyone disagrees?
Cheers,
Stefan
