On Monday 04 July 2016 01:52:41 Ricardo Signes wrote: > * p...@cpan.org [2016-07-03T08:39:22] > > > On Friday 01 July 2016 02:51:31 Ricardo Signes wrote: > > > What if we defined a role (here, just a well-known name) called > > > Email::MIME::Header::Value, which is used to signal that a > > > particular method, say "as_mime_header", should be used to > > > stringify? > > > > In this case, do we need role at all? Is not existence of method > > "as_mime_header" enough? > > That method alone is fine with me. > > > And all this would be passed via header or header_str? > > 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)... > > If address(), addrlist() and addrgroup() returns those objects > > (with as_mime_header() method) it could be usable... > > > > But I was thinking about using same syntax in Email::MIME for > > passing addrlist/addrgroup as is in Email::Address::XS > > format_email_addresses and format_email_groups functions. > > I'm afraid I don't understand what you mean. Syntax/API of passing email groups to function format_email_groups from Email::Address::XS module. E.g. to call format_email_groups and Email::MIME functions with same syntax of objects/structures/arguments.. > > In my opinion folding and unfolding should be done in > > Email::Simple. I'm not huge fan of adding folding and CRLF code > > into Email::Address::XS as it has nothing to do with it. That > > module parse and format one line of list of addresses. > > I agree. I think if we start with the API described above, and leave > the folding for the message to perform, we'll be okay. We can > certainly find out by writing the code! > > > > What do you think of this all? > > > > 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. > > Basically we need unambiguous way to specify: > > > > * ascii string which will never be MIME-encoded (error for unicode > > char) > > * unicode string which will be MIME-encoded if contains > > unicode char > > * addresses/groups - but again with ability to > > specify if do MIME-encode > > We have that, right? > > "header" is "already encoded", which is another way of saying "do not > encode this." Yes. > "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. > The address or groups thing falls under "object." I had assumed it > would, itself, know how to become MIME encoded. This is important, > because the semantics of what gets encoded differ per field type. > So, as_mime_header is the encoded form. If you want to offer an > unencoded form, as_string seems like the obvious method. 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.
