[Top] [All Lists]

Re: List variables in Sieve (Re: variables draft (draft-homme-sieve-variables-00.txt))

2003-04-21 07:45:05

On Sat, Apr 19, 2003 at 04:54:09AM -0700, 
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
After I rewrote my example in "imapflags" I've realised how ugly this will
look, because
1). The script author has to remember all flags that were set on the
message and specify them all.

Hm!  I thought of that as an advantage, not a downside.

2). setflags has to be replaced with multiple "set"s as we have to clear
all flags.

Similarly, I don't think that it's so bad that we get a list
of what flags are available that way.

Maybe we have very different applications in mind.  To me, the range
of flags is severely limited by the ability of clients to display
them and use them in the interface, and by the ability of users to
remember and use them.

Can you describe a typical application of your multitude of flags?

So, I am thinking now about using a single string parameter (instead of a
string list) that contains space delimited flags. Adding flags (old
"addflags") to the list would be simpler, e.g.

set "flags" "${flags} \\Seen"

I was wondering if we'd eventually get to this. I'm not delighted by it, but
I think it probably is the best solution to the problem.

I'd like to get a better understanding of the problem first.

This is introducing a second list type with roughly the same function
as the existing one, making sieve in the long term more expensive to
implement and harder to understand; because now, every time you specify
a list, you'll have to ask yourself whether it was type A or type B.

"removeflags" would be trickier to implement, but "string" test with
:matches can be used to test if a flag was set, e.g.

if string :matches "${flags}" "*\\Draft*" {
    set "flags" "${1}${2}"

The mistake in this expression -- it'll match \Draft as well
as \DraftBeer -- will be made many times over, and mostly without
harm, in scripts all over the world.  It can be fixed by using trailing
white space in both the matches and the flags string, but I don't
think most authors will remember to do that.

Very cute. How to folks who precompile all this stuff feel about allowing
this sort of variable pattern?

Well, you can't (precompile all this stuff), so what's the use.