* p...@cpan.org [2016-07-12T11:43:02] > On Monday 04 July 2016 01:52:41 Ricardo Signes wrote: > > > > I'd stick to header_str, I think, but I'm not sure. At any rate: > > yes. > > And this is what I do not like... to pass objects to function with name > header_str. That name sounds like it takes string, not object (or more > objects)...
Either we can add a new name, so people end up having to give "header_str" and "header_obj" or we can say "in general everything uses header_str, which follows these simple rules." I would rather do that. > > > Still do not know how to handle non-MIME headers correctly in > > > Email::MIME module. We can either create blacklist of non-MIME > > > headers and extend it every time when somebody report problem or > > > create whitelist of MIME headers... Or let caller to decide if his > > > header must be MIME-encoded or not. > > > > I'm sorry, I don't understand. Could you elaborate? > > If passed pair (header-name, header-value) needs to be MIME encoded or > not. Currently there is blacklist in Email::MIME for header names which > are never MIME encoded (like Message-Id, Date, ...) when passing as > header_str. So, I'd assume we'd go forward with: * if you know exactly octets you, the user, want in the header field, use "header", but this is likely rare * if you want to provide a string for a field that's pretty much just a string, use header_str and if it requires special handling, we do our best, which should get better over time * but if things are complicated, use an object that represents the structured data I don't like the idea that this will be broken further by adding the object behavior, though. $email->header_str_set($field => $email->header($field)); ...should not break things. > > "header_str" is "text string" which means it will get encoded. > > Not exactly, there are exceptions (Message-Id, Date, ...) plus special > behaviour for addresses headers. Those /mostly/ still get encoded, but we know that the strings are meant to be structured, so we try to deconstruct them and encode them correctly. I think those fields that get passed through unchanged are probably in error at least insofar as they let you put non-7-bit-clean data in your headers. This should probably be fatal: header_str => [ Date => "\N{SMILING FACE WITH HORNS}" ] > Addresses and groups are really something different as previous types > (strings). And if we threat them as objects, I would rather see e.g. > header_obj (or other different name) instead mixing it again with > header_str (which already have exceptions :-(). This is my initial > reason for header_addr/grps to distinguish it. My feeling is that Perl programmers are used to polymorphic interfaces, and that multiplying the number of ways to specify headers is a needless confusion. What is the benefit to the end user of splitting things up? -- rjbs
signature.asc
Description: Digital signature