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

Re: imapflags and variables

2003-05-12 14:22:34

On Sunday 11 May 2003 05:16, Kjetil Torgrim Homme wrote:
<snip>
Marc suggests a system variable for accessing the current value,
${#imapflags}.

Actually, I suggested a test for it, but ok.

you can get rid of ':globalflags_plus "Flag"' like 
this:

        keep :flags "${#imapflags} Flag";
<snip>

more like

  set "safe_flags" "${#imapflags}";
  addflag "Flag";
  keep :globalflags
  setflags "${safe_flags}";

I'll also note that the first snippet will misbehave with no
diagnostics if the user has forgotten 'require "variables"'.

"imapflags" would require "variables". I know that there's currently no 
extension that depends on another, but it's not uncommon. E.g. ESMTP's 
BINARYMIME depends on CHUNKING. Variables is a candidate that 
extensions will want to depend on.

my suggestion is to add a another action instead, only available when
the variables extension is in effect:

        STOREFLAGS <variable: string>
<snip>

The downside of that is that you need to come up with such an action for 
each and every extension that possibly wants to store away state 
temporarily.

for both proposals, :globalflags is sufficient, but verbosity is
slightly increased without :flags <flag-list>.  more radically, we
could remove both and make :globalflags the default and mandatory
behaviour for KEEP/FILEINTO.  this way the implicit keep can set
flags on the message.  I think that would be useful.

Rereading the "progressing various sieve drafts" thread, I get the 
impression that people were ok with :flags, but not with :globalflags. 
The main reason seemed to be that setflags/addflags/etc alter global 
state and that was a new thing for an extension to do.

Thus, there was thought about deferring this until variables are 
available. Says Tim:

On Wednesday 17 July 2002 19:49, Tim Showalter wrote:
On Wed, 2002-07-17 at 06:57, Ken Murchison wrote:
<snip>
I have -03 implemented in Cyrus and I find the global flags nature
very useful,
<snip>
That being said, I find the :globalflags stuff kind of crufty ;)

There's no argument from me that it's *useful*, but that it's cruft
that we'll need to replicate again and again in the future that looks
exactly like variables with an undesirable syntax.

So it seems to me that the feeling "back then" was to let extensions 
with actions that alter global state depend on a (then non-existant) 
variables extension. I think the variables extension needs to reflect 
this. I've proposed the "system variable" concept to this end, I'm open 
to other solutions.

Reviving the old action-affects-global-state method seems undesirable to 
me.

So how could imapflags progress in this light? I see two routes:

I non-system variables:

1. Dump :globalflags, keep only :flags. This means that implicit keep
   never sets any flags, but you can always end your script with an
   explicit keep (multiscript might make problems, though).
2. Iff - additionally - variables is required, then you can either
   2a. fill a user variable with flags and leave the whitespace,
      duplicates and ordering issues to the user. Dump
      *flags/mark/unmark.
   2b. introduce a required string argument to the *flags/*mark actions
      that specifies a variable name for the action to act on. The
      actions ensure validity of their arguments and maintain
      uniqueness, order and whitespace conventions inside the (user)
      variable.
   this way, you can emulate :globalflags with a explicit variable.

II system-variables / no tags

1. Dump :globalflags and :flags altogether.
2. Make imapflags depend on variables and introduce the system variable
   ${#imapflags}.
3. Make keep and fileinto use the current value of ${#imapflags}.
4. keep the set actions with alter #imapflags.


III system-variables / :useflags

like II, but fileinto and keep only use ${#imapflags} if the :useflags 
tag is present on them.

(I) has the advantage of being explicit, but requires the user to 
maintain the variables constraints herself, which is error-prone.

(II/III) have the advantage of being less error-prone, but are not 
_that_ explicit.

Either way, I don't see an approach that combines the advantages of 
both. I'd be glad to be shown one.

Marc

-- 
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.      -- Benjamin Franklin

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