On Thu, Apr 24, 2003 at 11:08:49AM -0700,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
[editheader]
I prefer the approach of having a single argument,
which can either be a string specifying a single field or a list
specifying multiple fields.
Hm, you mean a real ["foo", "bar"] list, or a chunk of text
that becomes the header?
I mean ["Comment: 1", "Comment: 2"].
If you're using ["foo", "bar"], you'll quickly run into the
lack of list operations and -variables.
I don't think so. But we can handle that fairly easily by saying empty
strings add nothing.
If you're using a big chunk of text, I think it will still have
to be parsed into names and values and checked or, more likely,
reformatted. I don't like doing that, not so much for efficiency
reasons but because it pretends to the script writer that they're
touching the true outgoing header when I really can't let them
do that.
I agree. I don't think the chunk of text approach is appropriate.
Do you have a usage scenario where a single string vs. multiple
makes a big difference?
Not really. It just looks better to have all of the fields added in a
single operation.
(2) I sure wish we'd allowed signed integers as numbers in the base sieve
specification. If we had them available we could use negative indices
to represent offsets from the last occurence of a given field.
Yeah, that would be nice, but I couldn't get it to work either.
OK. Just wanted to check and see if there was something I was missing.
(3) I see considerable value in addheader and deleteheader. Replaceheader,
however, goes a bit too far for my tastes. Do we really need this? Is
it worth the complexity?
The "replaceheader" command started out as a "tagheader" command
that just gave its user a choice of adding a prefix or a suffix.
The original audience for this was users with message stores that
don't support direct fileinto. They can tag their messages by adding
or changing the Subject: line, and then filter based on the Subject
line in their browsers.
Then people wanted an "untagheader" command, and didn't generally
respond well to the complexity of picking a header vs. the simplicity
of what I let them do it once they had it, so "replaceheader"
replaced the "tag" and "untag" versions and got a little more solid.
We can argue whether :newname has any business being there, though.
Good point. Even if we retain replaceheader I'd argue that :newname should
go. You can always get the effect by deleting and adding.
There's also the question of the interaction of a replaceheader
aimed at the third instance of one field being renamed to a field that
already exists.
<http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
Sequential execution of (unrelated) sieve scripts by the
environment. A meta-feature -- it doesn't define new sieve
language elements -- that's interesting in particular in
contrast to Cyrus's "include" draft.
Hmm. The approach taken here is very similar but not quite identical to the
approach I've used to combine multiple scripts. We agree in that any script
that ends in an implicit keep in effect cedes control to the next script
in the sequence, and that the explicit actions reject, fileinto, and
redirect that cancel implicit keep prevent subsequent scripts from running.
The place where we differ is in the handling of explicit keep. The draft
calls
for subsequent scripts to be called. I don't do that; in my implementation
an
explicit keep prevents subsequent scripts from acting.
Interesting. I've had some push-back about that, too, where colleagues
felt (and probably still feel) uncomfortable that the system would react
to an explicit command with this big-brotheresque "well, you're saying you
want to keep the message, but what you _really_ may want is to give it the
default trailing script treatment".
I don't think this is something I can change at this point either. One of
the
things that's often done is to have some kind of filtering in a system-level
sieve script. That script may elect to discard a message. I wanted the
ability
for users to override such system-level decisions by issuing an explicit
"keep" in their scripts. This trick got documented and is now in use.
We'd just have used "fileinto "INBOX"" for that, but okay. And of
course you might not have "fileinto".
Good point. Since I implement it I tend to forget it is optional...
There's also one semantics issue I see here: RFC 3028 says that fileinto
"INBOX" and "keep" are equivalent in an IMAP environment. This specification
tweaks that equivalence somewhat.
Yeah, I know...
I guess the alternative here is to make explicit keep and implicit
keep once again behave differently. That's ugly, but it does seem
to be closer to expectations.
Did you ever run into a situation where that gave you trouble --
where you wished you could have an explicit implicit keep?
I don't believe I ever have. But it is hard to predict what is going to
happen once variables are available. I suspect they are going to
change usage patterns fairly substantially, and it is hard to know which
of these little quirks of the language are going to prove problematic.
Ned