ietf-mta-filters
[Top] [All Lists]

Re: Variables : list : scope : system : const

2003-05-09 04:56:08

[Ned Freed]:

  > > this could be solved by making making a new list variable syntax,
  > > e.g., @{folder} becomes a list, while ${folder} 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.

what's your preferred alternative in the imapflags case?

  There are also very substantive syntactic difficulties with making
  such usage compatible with the base sieve specification.

please state them so that they can be addressed.

  > 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.

I agree.

  > 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.

what do you mean?

  > 6) If we really want a class of variable that can't be written
  > to then lets implement const variables.
  
  Vastly too complex IMNSHO.

well, it's the alternative to system variables, which I find vastly
too complex ;-)

  > 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.

obviously I'm with Nigel on this one.

  > 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?

I'm wary of tests setting variables.  (sometimes I wonder if the
convenience of ${1} is worth it.  SETMATCH ["user", "domain"] (meaning
SET "user" "${1}"; SET "domain" "${2}") is a reasonable alternative,
but quite a bit more verbose.)

  > Access to mailbox/domain configuration for server/domain scripts
  > to decide how best to filter messages in those scripts?

I don't understand this ...

  I see no need for it. Existing extensions can be used to do this.

... so this intrigues me :-)

  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.

I agree, but a powerful variables concept may pay off when
implementing later extensions.  I think it is important that we try to
keep the language and mechanisms coherent, and add features that
complement each other and are more powerful in unison.

-- 
Kjetil T.