On Tue, 2005-02-08 at 11:02 +0000, Nigel Swinson wrote:
Ok, so what if we have an action which requests certain variables
associated with an extension to be made available in it's namespace.
setvariables <extension-name: string> [<list-of-variables: string-list>]
If you don't supply a list of variables that you want access to, it
will activate all variables the extension defines, else it will only
activate the list of variables that you were interested in. This
might help with the issue of only wanting to use processing resources
(av/as?) for some messages.
the analysis of the script to find the variables actually used is so
trivial I don't think it is worthwhile to burden the script writer with
replicating it.
I don't think it is meaningful to add a general function. consider
SETDATE, which had an optional parameter for the timezone.
for many extensions, I don't think an explicit action is needed, and in
my view that includes the spamscore extension. there is one advantage
to doing it, though. if you require only "spamscore", and not
"variables", strings like "${spamscore.value}" will still be legal, they
will just not be interpreted. a separate extension name which makes a
setter function available may make such errors less likely.
--
Kjetil T.