On Friday 01 July 2016 02:51:31 Ricardo Signes wrote:
> My coworkers have returned to the other side of the world!  I
> attended YAPC!  i had a vacation!  I am back.
> 
> * p...@cpan.org [2016-06-01T12:44:01]
> 
> > On Tuesday 31 May 2016 02:42:48 Ricardo Signes wrote:
> > > * p...@cpan.org [2016-05-28T16:48:40]
> > > 
> > > > Basically yes. From caller perspective I want to pass email
> > > > address object and let Email::MIME to do MIME encoding
> > > > correctly. Something like this:
> > > > 
> > > > my $email = Email::MIME->create(
> > > > 
> > > >         header_addr => [ ... ],
> > > > 
> > > > );
> > > 
> > > I think that requiring people to break headers up even further
> > > into to add a "header_addr" argument is a bit much.  And why
> > > header_grps?
> 
> So, you had some responses to this which were quite helpful.
> 
> My suggestion was meant to be something like "why not make
> Email::MIME understand some kind of object as the value in a
> header?"  I think this is still right.
> 
> Your main responses were (please correct me if I am misunderstanding
> them):
> 
> 1.  it should be possible and easy to supply a list of address
> objects
> 2.  it should be possible to have a named group, but not
> required

Both 1. and 2. are required and 1. should be easy to use by caller. 2. 
is not so common, but still email module should be able to support such 
thing.

> 3.  we don't want ambiguity in how objects passed to
> (header_str => [...]) are interpreted

Yes!

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

> When building the header, the code will do something like:
> 
>   $string = $name . ": "
>           . ($value->DOES('Email::MIME::Header::Value')
>               ? $value->as_mime_header
> 
>               : "$value");
> 
> No existing object will become confused by this change, only objects
> which do the new role.
> 
> Then Email::Address::XS could provide some helper routines, so you
> could write and of:
> 
>     From => 'r...@cpan.org'
> 
>     From => Email::Address::XS->new(...)
> 
>     From => address('r...@cpan.org', 'Ricardo SIGNES')
> 
>     From => addrlist( address('r...@cpan.org', 'Ricardo SIGNES'), ...
> )
> 
>     From => addrgroup( Humans => address('r...@cpan.org', 'Rik'), ...
> )

And all this would be passed via header or header_str?

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.

> It might be best to make the first code sample actually do:
> 
>   $string = $name . ": "
>           . ($value->DOES('Email::MIME::Header::Value')
>               ? $value->as_mime_header($name, $mycrlf)  # <-- changed
> 
>               : "$value");
> 
> ...to let the object do folding.  I'm not sure about that one.  I'd
> want to double-check whether there's a reason to not always do the
> folding of the post-stringified form in Email::MIME.

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 think that automatically adding CRLF into output string is not good 
idea. But maybe it could make sense to tell Email::Address::XS module to 
"prepare" output string in format that it can be split by greedy 
algorithm for lines which are XX chars long (maybe 72 by default?).

But now I'm not sure if it is possible... Email::Address::XS know 
nothing about MIME or encodings. It just format what caller pass it...

> Anyway, this avoids adding multiple more places to set headers and
> makes the API extensible for other header types like Message-ID,
> etc, in the future.
> 
> 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.

And I think that it is better to let caller decide and do not do any 
magic (decide based on header name if MIME-encode or not). As adding any 
entry into black/white-list could cause breaking existing SW when update 
to new Email::MIME module.

My attempt with header_addr and header_grps achieve it. Passing objects 
with own as_mime_header() method could work too (problem is with that 
folding). But reason why I proposed header_addr and header_grps is 
ability to directly pass input to / output from Email::Address::XS 
functions (without need for anther transformation and (de-)composition 
of objects.

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

Reply via email to