Re: Three new drafts and a question

[[e-mail]]

> On Thu, Apr 24, 2003 at 11:08:49AM -0700, [e-mail] 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