Groups | Search | Server Info | Login | Register
| Newsgroups | perl.pep |
|---|---|
| Date | 2016-06-30 20:51 -0400 |
| Subject | Re: Email::Address::XS |
| Message-ID | <20160701005131.GA27257@debian> (permalink) |
| References | <201605231905.43786@pali> <201605282248.54159@pali> <20160531004247.GA28184@debian> <201606011844.08148@pali> |
| From | perl.pep@rjbs.manxome.org (Ricardo Signes) |
[Multipart message — attachments visible in raw view] - view raw
My coworkers have returned to the other side of the world! I attended YAPC! i
had a vacation! I am back.
* pali@cpan.org [2016-06-01T12:44:01]
> On Tuesday 31 May 2016 02:42:48 Ricardo Signes wrote:
> > * pali@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
3. we don't want ambiguity in how objects passed to (header_str => [...])
are interpreted
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?
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 => 'rjbs@cpan.org'
From => Email::Address::XS->new(...)
From => address('rjbs@cpan.org', 'Ricardo SIGNES')
From => addrlist( address('rjbs@cpan.org', 'Ricardo SIGNES'), ... )
From => addrgroup( Humans => address('rjbs@cpan.org', 'Rik'), ... )
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.
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?
--
rjbs
Back to perl.pep | Previous | Next — Previous in thread | Next in thread | Find similar
Email::Address::XS pali@cpan.org - 2016-05-23 19:05 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-05-28 16:33 -0400
Re: Email::Address::XS pali@cpan.org - 2016-05-28 22:48 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-05-30 20:42 -0400
Re: Email::Address::XS pali@cpan.org - 2016-06-01 18:44 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-06-30 20:51 -0400
Re: Email::Address::XS pali@cpan.org - 2016-07-03 14:39 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-07-03 19:52 -0400
Re: Email::Address::XS pali@cpan.org - 2016-07-12 17:43 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-01 19:00 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-02 23:03 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-02 18:36 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-08 23:41 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-18 17:21 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-18 23:35 +0200
Re: Email::Address::XS pali@cpan.org - 2016-08-20 12:01 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-22 22:34 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-23 09:56 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-24 22:55 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-25 09:40 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-09-03 18:24 -0400
Re: Email::Address::XS pali@cpan.org - 2016-09-05 10:25 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-09-11 18:58 -0400
Re: Email::Address::XS pali@cpan.org - 2016-09-12 09:26 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-09-16 18:37 -0400
Re: Email::Address::XS pali@cpan.org - 2016-09-18 01:05 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-09-18 11:26 -0400
Re: Email::Address::XS pali@cpan.org - 2016-09-18 17:40 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-09-28 09:29 -0400
Re: Email::Address::XS pali@cpan.org - 2016-09-30 12:38 +0200
Re: Email::Address::XS pali@cpan.org - 2016-11-13 03:17 +0100
Re: Email::Address::XS pali@cpan.org - 2016-11-13 03:24 +0100
Re: Email::Address::XS pali@cpan.org - 2017-01-14 21:32 +0100
Re: Email::Address::XS pali@cpan.org - 2017-01-23 14:44 +0100
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2017-01-28 15:48 -0500
Re: Email::Address::XS pali@cpan.org - 2017-02-14 21:26 +0100
Re: Email::Address::XS pali@cpan.org - 2017-03-08 00:03 +0100
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-22 22:26 -0400
Re: Email::Address::XS pali@cpan.org - 2016-08-23 09:50 +0200
Re: Email::Address::XS perl.pep@rjbs.manxome.org (Ricardo Signes) - 2016-08-23 09:31 -0400
Re: Email::Address::XS pali@cpan.org - 2017-02-18 21:25 +0100
csiph-web