(Ug, I go away for a long weekend and come back to 50 messages from this
list along... I've only just caught up.... I've probably missed some stuff
that I wanted to say, but I'll try to stick it all in one post. I'm
starting a new thread, cos it's strayed somewhat from just discussing "date
variables")
this could be solved by making making a new list variable syntax,
e.g., @{folder} becomes a list, while ${folder} is becomes a single
string with a single space as delimiter or something.
With all the stuff and points that are getting raised I'm becoming
increasingly convinced that:
1) We should implement list variables (maybe even associative variables),
and implement the imapflags extension using the list variables. Perhaps one
extension that deals with the syntax, the operators (including operators to
turn it into a string), or perhaps it could be part of the imapflags one...
I'd prefer them separate I think... If we implement imapflags without list
variables, then get further down the line and find we can't live without
them, then we'll just end up wishing we had them for the imapflags
extension.
2) We should provide a proper scoping mechanism, if that be
scope.variablename then so be it :o) I'd prefer :: for scope, as that's
certainly much more familiar. Would that syntactically be allowed?
3) All variables that are ever defined in any RFC extension must be in some
kind of scope.
4) The only "unscoped" variables would be defined by the user and would be
in the "default scope".
5) We don't have any "system variables" or "magic variables", JUST
"variables". So if we want setdate to produce variables for us to use
elsewhere then they either go out to some associative array, or a set of
variables in an appropriate namespace that can subsequently be written to if
the script author so desires. I don't want to have to deal with two+
classes of variables :o(
6) If we really want a class of variable that can't be written to then lets
implement const variables.
7) If we have variables that can only get modified by fancy operators like
addflag, removeflag, I'd rather that I couldn't even access them through
${#imapflags}" etc, but instead have an expicit set action somewhere that
put the value into a general purpose, bog standard variable, just like all
my other variables that I could them manipulate in any way I wanted.
BTW another thing I'd like to be able to do is gain access to the spam score
or virus name to use for prepending the subject field. Perhaps we'd want a
special automatic variable for this too? Access to mailbox/domain
configuration for server/domain scripts to decide how best to filter
messages in those scripts?
It seems that the initial goal of Sieve was to make a fool proof scripting
language, but it seems we want to do "more than a fool" would want to do
with it. So I recon either we don't allow all these "complex" extensions
like variables, or we do it properly, and scalably, and we end up heading
towards an email tailored, fully fledged programming language... Scope,
const, array, list, this seems to be a whole stack of issues that have been
solved properly by other programming languages, and we're just shying away
from implementing them properly cos we're trying to keep it simple :o(
Maybe for those servers that have nothing but "fools" as users, they just
won't let them use all these extensions like the variables extension, which
will leave Sieve pretty simple like it is in the base RFC.
Hmmm, why do I feel like I'm about to be flamed? :o)
Nigel