[Ned Freed]:
[Jutta Degener]:
> [editheader]
interesting, the draft says "replaceheader". "editheader" is a better
name, especially if :newname goes away.
> [Ned Freed]:
> > 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"].
I don't follow. could you write an example?
addheader ["Comment: 1", "Comment: 2"];
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"];
you could do a list of header names with replaceheader as well, but
the counting is a bit tricky, and I think it's complex enough already.
you can always do N separate replaceheader instead.
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 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?
Good point. Even if we retain replaceheader I'd argue that
:newname should go. You can always get the effect by deleting and
adding.
if there is only one header, yes.
if header "Message-ID" :matches "<*(_at_)*>" {
deleteheader "Message-ID";
addheader "Old-Message-ID" "<${1}(_at_)${2}>";
addheader "Message-ID"
"<my(_dot_)${1}(_dot_)${2}(_at_)example(_dot_)com>";
}
if there is more than one instance of a header, you can't get at one
of them in particular. the content in ${N} could be from the first or
last or a random one.
This argues for adding index capabilites to header, which is something we
need independently of this facility.
this might be an issue for the variables draft, it could say that the
search must be short-circuited (given, but perhaps not strongly enough
worded in existing documents), and the search done in first to last
order. would that be appropriate?
I have no problem with nailing down first to last scanning order for multiple
versions of the same field. But keep in mind that this doesn't solve the entire
problem: You can potentially have three iterates in a header operation: A list
of field names, a list of field values, and more then one instance of a given
field. I suspect different implementations organize their iterates differently
(I iterate on field, field instance and finally field value myself). I don't
think we want to mandate a particular way of ordering the iterates.
Of course you can work around the iteration order by using simpler tests,
whereas you can't work around the problem of multiple fields other than
by specifying the short-circuit behavior to some extent.
Ned