On Friday 02 May 2003 01:04, Kjetil Torgrim Homme wrote:
<snip>
the current list is ${year} ${month} ${day} ${hour} ${minute}
${second} ${timezone}, all numeric and zero-padded.
There are two issues I have with this:
1. We define magic variables and don't provide a mechanism for other
extensions to register their own magic variables.
2. We combine two basically unrelated extensions ("variables" and
"dates") into one.
Short comment: Define a namespace for magic variables and move the date
variables out into the to-be-written draft defining the date test.
Long comments:
Let's assume for the moment that "variables" didn't include "dates", but
defined a syntax for magic variables[1]. "dates" would encompass the
date test Ned wanted to write an I-D for and - in the presence of the
"variables" extension - would define certain magic variables "#year",
"#month" etc.
ad 1: Change the variable-name production to read
variable-name := num-variable / magic-variable / user-variable
magic-variable := "#" identifier
user-variable := identifier
and require every Sieve extension to define their magic-variables and
which commands change their state and how. This is more like how common
script languages (bash, awk, perl,...) work and it provides a namespace
for magic (or "system") variables alike to perl's $<non-alnum>
variables.
ad 2: The "dates" extension would then use this mechanism to declare
#year, #month, #day, #hour, #minute, #second and #timezone to be system
variables that are initialized to their respective values of the time
of script execution start (local timezone). Since the "setdate" action
now didn't really set the date variables anymore, it would better be
named "settimezone". If executed, these system variable values are
recomputed, based on the new timezone given to "settimezone", but still
representing the time of script execution start.
To see the benefit of the system variable notion, consider the imapflags
extension. This would now declare the #imapflags system variable that
holds the current flags (e.g. as a list of imap flag names separated by
spaces). addflags, setflags and removeflags would then act on the
#imapflags variable, but
set "#imapflags" "${#imapflags} \\Seen"
would be OK, too, of you accept the fact that you can cause problems if
you forget the space before "\Seen". Basically, if you assign to system
variables, it's your own fault. Alternatively, assignment to system
variables could be disallowed. I think would be the the best way to
handle it, since it also prevents users from defining variables in the
system namespace (which wouldn't be too problematic, given that system
variables spring into life only if their extension is require'd).
Fileinto would then use the value of #imapflags to determine the flags
to set on (e.g.) IMAP APPEND.
Comments?
Marc
[1] Those that are either implicitly changed by commands or are
automatic in the sense that the environment provides them w/o explicit
instruction (with can be rephrased as: "are set implicitely by the
require command requesting the corresponding extension"). For
concreteness, let's assume they must all start with a hash '#'.
--
If this were a dictatorship, it'd be a heck of a lot easier...just as
long as I'm the dictator...
-- George W. Bush, Washington, DC, Dec 18, 2000,
during his first trip to Washington as President-Elect
pgpeHaRijBQji.pgp
Description: signature