[Top] [All Lists]

Re: dynamic naming & creation of mailboxes

2003-01-13 20:00:55

[Nigel Swinson]:

  5.  Action setdate
     These variables SHOULD reference the time when execution of the
     Sieve script reaches the statement.  The local timezone SHOULD
     be used.
  The local timezone is going to be the timezone of the server,
  which may not be the "local" timezone for the user.  I would
  suggest that this be a UTC time, as then there will only be one
  time conversion to do, rather than potentially two.  ie I check my
  mail from the US East coast, the server is US West coast.
  "localtime" US West coast isn't so useful to me.

heh, yeah.  I guess this is different for people in the US and other
large countries which span several timezones.  however, I think it
will be confusing and annoying for users to have their mail archive
switch to a new folder seven hours before midnight.  perhaps allow the
user to specify timezone explicitly?  but then there's the issue of
daylight savings time.  ugh.  AFAIK, there is no IANA registry for
timezone information.  we could use POSIX syntax, but it's pretty
cryptic, e.g., in Central Europe the correct value is
"MET1METDST2,M3.5.0,M10.5.0".  this is OK if your OS supports it, but
I'd hate to write the code myself!

how about adding an optional argument of the form +HHMM or -HHMM, and
punt on the daylight savings issue.  if the argument is left out, use
localtime.  this way small ISPs, universities etc. can offer the
"natural" behaviour without requiring their users to jump through
hoops.  if you want UTC, use setdate +0000.

  Also part of the point of Sieve is that your filter will do the
  same thing on any server.

is that a requirement, or just a Good Thing?

  And then what if you run an ISP with mailservers in several
  timezones.  If the script uses the local timezone, then this means
  that you can't move users to different timezones without modifying
  their sieve script.

that was the reason for SHOULD.  a multinational ISP would probably
use UTC.

     a) Should we include more predefined variables to access the time?
     (hour, minutes, timezone, weekday, week number (US, EU og ISO?), name
     of month, name of weekday, ...)  Could use strftime(3c) as a list of
     what to offer, but the names should be in English.
  Don't really follow why we need ${dollar} at all.  Most of the
  time $ won't be followed by {

true.  I included it to have a simple way to quote arbitrary text for
inclusion in a script without parsing them, like s,\$,\${dollar},g

  and if we want it to then \${ or $\{ will escape it for us.

no, it won't.  backslashes are resolved before variables are
substituted.  I didn't want to change that part of the original Sieve
specification.  but, the user can actually

   set dollar "$"
   set text "regarding ${dollar}{dollar}"

if the need arises.  so it is really superfluous.  I'll fix the draft,

  Incidentally how should we behave if the "}" is missing?
  Presumably treating it as illegal.  Perhaps there should be an
  example about this...

yes.  the parser should terminate its search for } as soon as an
illegal character has been found [^a-z0-9_] (most likely a space
character), and copy the syntax error(?) verbatim.

   set var "something"
   set text "hi ${junk ${var}}"

text now holds the value "hi ${junk something}".

  hour, minutes, name etc are probably more useful predefined
  variables than the dollar, and mean you don't have to call

my first version of the draft had them as builtins.  I used
case-sensitivity to mark them as reserved names (if the first letter
was uppercase, assignment was illegal).  but case sensitivity is a bad
idea, and I think it is cleaner to have no magic reserved words,
unless the user explicitly asks for them.  it also allows the user to
influence the values, cf. timezone discussion above.

  In fact given how cheap it is to do a "set date" action, it might
  actually be better to just do the setdate in a lazy fashion, when
  a reference to a time is requested, rather than have to bother
  calling setdate.

it is important not to be too lazy.  you want all the time variables
to be set at the same time, or else you risk mail falling between

  if string "${hour}" "00" {
  } else if string "${hour}" "23" {

if the mail arrives at just before midnight, the first test fails.
then the clock ticks, and the second test fails also.  (with setdate,
the user is allowed to shoot himself in the foot.)

              fileinto :makefolder "archive.${year}-${month}";
     It is not clear if this feature should be included here or left
     for a separate extension.
  Separate extension.

ok.  I agree, it just that it's such a tiny extension :-)

     c) Should the modifier syntax be prefix or postfix?  ${var.lower} may
     be more natural than ${lower:var}.
  Prefix.  More "function call" like

yeah.  to clarify "more natural": I used prefix since that is what I'm
used to from bash programming (which has horrific syntax, btw :), but
thought of postfix when I had to write that the modifiers are applied
right to left (which is the natural way of doing it).  with postfix,
the order of the modifiers matches the syntax.

     d) Should references to unknown variables be left in place (rather
     than replaced by the empty string) to ease debugging scripts with
  Set to null, as perhaps a "set =" is only executed in one of the
  if blocks, so it's not an "error" that needs debugged if we didn't
  go through the if.


thank you for your feedback!

Kjetil T.                       |  read and make up your own mind

<Prev in Thread] Current Thread [Next in Thread>