BTW I think this is the kind of extension that could be solved with
better fundamental language elements and/or better coordination between
language extensions.
For example, one could build on the proposed "variables" extension by
imagining a new set of read-only variables within specific namespaces
(per the old namespace idea, a la dates and timezones). Imagine:
require "variables";
require [ "relational", "comparator-i;ascii-numeric" ];
set "spamval" "${spamtest::value}"
set "spampct" "${spamtest::pctvalue}"
set "spamtext" "${spamtest::text}"
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamval}" "3" { ... }
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamtest::pctvalue}" "30" { ... }
Time travel might be required though.
Or better still why not just refer to the variables direct in the string test?
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamtest.value}" "3" { ... }
if string :value "ge"
:comparator "i;ascii-numeric"
"${spamtest.pctvalue}" "30" { ... }
This is certainly on a similar tack to my post relating to associative arrays
and sms notification, so unsurprisingly I would really like to see something
along these lines, but I'm not sure how we get there. Indeed I think it's
this kind of thing that gives the variables extension a large amount of it's
value. The variables spec does make reference to:
Namespaces are meant for future extensions which make internal state
available through variables. These variables SHOULD be put in a
namespace with the same name as its capability string. Notice that
the user can not specify a namespace when setting variables with SET.
I wondered if we would therefore say things like if you require "spamtest",
then a namespace called spamtest would be defined containing variables called
value and text which contain etc. It then seems to make sense to specify in
the spamtest spec what variables it would define. Do we have time to add such
a section to spamtestbis?
One problem here is that it costs resources to obtain the spam score and virus
score, and part of the reason you might be using sieve would be to refine which
messages would result in those resources being used up. So you might still
want to somehow specify or recommend that the implementation make the variables
in the namespace available in a lazy fashion.
Nigel