[I've modified the subject once again to reflect our current discussion].
Jutta Degener wrote:
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.
See below.
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?
I am think from the point of view of a user writing scripts by hand, not scripts
generated by UI.
Also, I am thinking more in IMAP terms, i.e. each script is a list of blocks
like
this:
if <condition> add/remove <flag>;
I don't want an end user to require to remember at each point in the script
which
flags are to be set on the message.
IMHO, this reduces script complexity and, as a result, user errors.
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.
I don't think I share your concern. If you are afraid that this will open gates
to
multiple Sieve extensions that misuse strings,
Sieve mailing list exists not to let such extensions be standardized.
All functionality required is already available in the base Sieve document or
the
variable draft. So, my proposal doesn't make it harder to implement.
Besides, if you want to be explicit, you can still use "${flag1} ${flag2}
${flag3}" construct instead of specifying a single variable.
So, UI-generated scripts are still possible with my proposal.
And yes, I grew up as a Pascal programmer as well and I miss set types and set
related operations ;-).
"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
Good catch.
-- will be made many times over, and mostly without
harm, in scripts all over the world.
Hopefully, if a correct example is shown in the document, everybody will just
cut&paste it.
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.
Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK
Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
I speak for myself only, not for my employer.
__________________________________________