develooper Front page | perl.pep | Postings from July 2016

Re: Email::Address::XS

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
July 3, 2016 23:52
Subject:
Re: Email::Address::XS
Message ID:
20160703235241.GA26626@debian
* pali@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.

> 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.

> 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?

> 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."

"header_str" is "text string" which means it will get encoded.

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.

-- 
rjbs

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About