[Email-SIG] email.header.decode_header eats my spaces
Stephen J. Turnbull
stephen at xemacs.org
Thu Mar 29 08:35:06 CEST 2007
Barry Warsaw writes:
> Steve writes:
> > IMHO, the Header class should be abstract, and there should be
> > subclasses that handle dates, lists of addresses, lists of
> > message-ids, etc.
> I'm not sure inheritance is the right way to organize this.
I picked inheritance because I see the header "type" as being fixed at
Header instantiation (I can't think of a use-case for changing a
"From" header to a "Subject" header, while "Message-ID" and
"Resent-Message-ID" would be handled by the same class), but there are
some things (handling folding, parsing the field name and body) that
are common to all headers.
I would be happy with any scheme that has the property that given a
field name, the semantics of its contents are fixed according to the
field if it is registered, or treated as "*text with caution" (maybe
extra warnings? etc) if the field is not registered.
> Or, maybe inheritance is right. In any case, I think you also want
> to also have a registry of some sort
Indeed I do!
More information about the Email-SIG
mailing list