>> Actually I think what I'm proposing will make it easier for a gui, not
>> harder.
>
> Perhaps in this specific case, but in general, no. The problem with the
> idea
> of having "special" variables show up is that it won't be limited to
> accessing
> the header. You yourself used the notion of extending it to spamtest. This
> sort of thing requires fairly deep knowledge of each extension in the GUI.
I can see it's a nice goal to have a generic gui for building any old sieve
script, but I don't think we can really get away from having to do some
development work for each extension to make it available more neatly to the
user.
For seamless integration, sure, but it would really be nice if basic
integration didn't require such in-depth knowledge.
> I'd much rather have the binding from various information sources to
> variables be explicit. It may not be possible to present this sort of
> thing in a very pretty way, but at least it should be possible to
> accmodate
> extensions more easily.
Could we instead say that the spamscore namespace is populated after the
first instance of using the spamtest test?
This makes some things better, others worse. Better in the sense that
at least the variables aren't quite as magic. Worse in the sense that
it creates a magic side effect.
That would make my magic string:
if spamtest :matches "*" {}
addheader "X-Spam-Score" "${spamscore.score}";
Slightly better, but still a bit ugly... Perhaps instead define some new
action who's sole purpose is to populate the spamscore or header namespace.
That's a much better idea, actually. I could live with this approach.
Something like:
headervariables list-of-header-fields
We could even make the "header." prefix settable.
Something like the getdate (?) action from a much earlier revision of the
variables spec?
I believe it was setdate, but yes, I found the setdate thing to be fairly
reasonable.
>> I've had to solve this in the past by having large "magic strings" like
>> this:
>
>> if spamtest :matches :comparator "i;ascii-numeric" "*" {set "spamscore"
>> "${1}";}
>> addheader "X-Spam-Score" "${spamscore}";
>
> Which I think is fine.
>
>> Where the presence or absence of the entire two lines is controlled by a
>> checkbox. It would have been much easier if I had a ${spamscore.score}
>> or a
>> ${MESSAGE['SpamScore']} available to me.
>
> Yeech. This is exactly the sort of thing I think we need to avoid at all
> costs.
If you like my existing magic string, then you could rephrase my request to
say that I'd like to change my magic string to just:
addheader "X-Spam-Score" "${spamscore.score}";
What's Yeech about that? It's less than half the syntax and the intent is
much clearer.
The issue was more the array notation and the creep into multiple extensions.
Ned