[Top] [All Lists]

Re: variables: open issue a) date variables

2003-05-02 16:08:35
On Friday 02 May 2003 01:04, Kjetil Torgrim Homme wrote:
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> 

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.



[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

Attachment: pgpeHaRijBQji.pgp
Description: signature