[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