On Sun, 15 Oct 2006, SeattleServer.com wrote:
> Custom names will be handy. How will they be named? acl_m_foo,
> acl_c_bar? Or will they be more freeform names that need the scope
> declared?
Currently available in the nightly snapshots. From the ChangeLog:
1. ACL variables can now be given arbitrary names, as long as they start with
"acl_c" or "acl_m" (for connection variables and message variables), are
at least six characters long, with the sixth character being either a digit
or an underscore. The rest of the name can contain alphanumeric characters
and underscores. This is a compatible change because the old set of
variables such as acl_m12 are a subset of the allowed names. There may now
be any number of ACL variables. For example:
set acl_c13 = value for original ACL variable
set acl_c13b = whatever
set acl_m_foo = something
What happens if a syntactically valid but undefined ACL variable is
referenced depends on the setting of the strict_acl_vars option. If it is
false (the default), an empty string is substituted; if it is true, an error
is generated. This affects all ACL variables, including the "old" ones such
as acl_c4. (Previously there wasn't the concept of an undefined ACL
variable.)
The implementation has been done in such a way that spool files containing
ACL variable settings written by previous releases of Exim are compatible
and can be read by the new release. If only the original numeric names are
used, spool files written by the new release can be read by earlier
releases.
> What do you think of the hash/array variable idea? I suppose unlimited custom
> names would^Wmight work in this instance, but in some instances hashes are
> cleaner.
I'm afraid I haven't been paying any attention to the discussion. I
suspect it's pushing the concept of the Exim design (which has already
been pushed rather a long way... :-)
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
