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.
I agree. The need for extension-specific parameters makes a general function
infeasible.
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.
I agree here as well. The cost of doing what's necessary to bind a fair
number of different variables to a set of values is the only thing that
makes this whole idea somewhat attractive. But the code of binding
one or two variables, which is what you'd have in the case of spamtest
or virustest, is so short that I just don't see the need for a separate
variable binding action.
Ned