(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.
I disagree 100%. I think this is far too complex. There are also very
substantive syntactic difficulties with making such usage compatible with
the base sieve specification.
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?
I can live with this as a naming convention. Scoping, however, is more than a
naming convention. I object to scoping on this basis as it is far too
complex.
3) All variables that are ever defined in any RFC extension must be in some
kind of scope.
A naming convention is fine, scoping is not.
4) The only "unscoped" variables would be defined by the user and would be
in the "default scope".
A separate naming convention for user variables is fine.
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(
You may not want to deal with them, but it may make sense to implement things
using a multi-tiered storage approach.
6) If we really want a class of variable that can't be written to then lets
implement const variables.
Vastly too complex IMNSHO.
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.
This doesn't bother me either way.
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?
I see no need for it. Existing extensions can be used to do this.
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(
Simplicity per se is not the issue, nor is the ability for fools to write
scripts. The central concerns here all revolve around implementability,
performance, and security. When complexity comes up as a concern, it is because
something is seen as being too difficult to implement in the context of a a
high performance messaging server. Things like lists, associative arrays, and
so on raise the bar hugely, creating implementation complexity and thereby
increasing the risk of security problems.
Like it or not, few programming languages are designed with these sorts of
constraints in mind. This means the willy-nilly importation of features from
other languages tends not to work very well.
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.
Even servers that serve fools have have script construction facilities. And
even if this weren't true, this is a strawman since usage simplicity isn't
the central concern here.
Ned