[Ned Freed]:
> I don't follow. could you write an example?
addheader ["Comment: 1", "Comment: 2"];
I don't like mixing the header name and the content. I don't see what
this buys you compared to two calls to addheader.
OK, I'm now convinced this was a bad idea on my part. Having multiple
addheaders also seems preferable to me given that we don't really want
to encourage wholesalle header additions.
> list of header names makes sense with deleteheader, but for
> addheader I think it makes more sense to only support a list of
> values.
>
> addheader "Comment" ["1", "2"];
Ick. This merely adds complexity without actually adding the issue:
addheader ["Comment: 1", "Content-description: 2"];
see above :-). adding two instances of a header is very uncommon, so
it's not a very useful feature. it's more of a general design
principle: do we want to support lists rather than single strings
wherever we can give the action a useful meaning?
I do feel that keeping the header name separate is best, if only for
consistency with deleteheader and replaceheader.
Consistency with header is actually more important IMO.
I think replaceheader is too complex. Think for a bit about the
right way to handle modifications to encoded words. It gets very
very nasty in a great big hurry. For example, suppose I have an
encoded-word in iso-8859-1
"invisible" to Sieve. the string will be in Unicode.
Yes, that's one way to implement it, and probably the approach I'd take. But
now when you apply replaceheader it ends up affecting parts of the field that
weren't specified in the action. Least astonishment principle and all that.
Of course a deleteheader/addheader sequence has the same characteristics.
But in this case it is very clear that the old header is gone and has
been replaced with something else.
and I use replaceheader to change an a with an accent grave to an
a with an ogonek. What does the result look like? Are adjacent
encoded-words affected? Should they be?
I think a fresh re-encoding is the way to go. regrettably there are
some clients with limited support for charsets, so it would be nice if
the Sieve implementation tried to use the same charset as was used
originally, if only one charset suffices. encoding it all as UTF-8
should be good enough, though. remember that the user must explicitly
request this munging. if his e-mail client can't handle it, he should
turn it off.
I agree with this implementation choice, but it begs the question of why
deleteheader/addheader aren't sufficient in the same way that
a sequence of addheader actions is sufficient to avoid the use of lists
in addheader.
Ned