On Saturday 14 January 2017 21:32:57 p...@cpan.org wrote:
> On Sunday 04 September 2016 00:24:56 Ricardo Signes wrote:
> > If we never *store* objects, but only produce them as requested, then
> > I think the total needed changes are -- but I'm sure I'll miss
> > things -- as follows:
> >
> > *
On Sunday 04 September 2016 00:24:56 Ricardo Signes wrote:
> If we never *store* objects, but only produce them as requested, then
> I think the total needed changes are -- but I'm sure I'll miss
> things -- as follows:
>
> * allow header_str and header args to Email::MIME->create to include
>
removing pointer to that module will not be
> needed..
Now I created pull request for Email::MIME:
https://github.com/rjbs/Email-MIME/pull/32
It should contains only code cleanup and fixes, no Email::Address::XS...
Look at it and if there are some problems, let me know!
MIME encode those broken outputs.
>
> Email::Address::XS has (looks like) correctly implemented formatter and
> so it is needed to correctly MIME encode From/To/Cc/Bcc headers.
I suggest making Email::MIME use Email::Address::XS if it is available, and
adding Email::Address::XS to th
rn as long as it has those two methods.
> But I think we're on the same page.
OK!
> The Email::Address::XS use should be optional, as right now people
> can install Email::MIME in an compiler-free environment. We can add
> it as a recommended prereq.
Currently passing string values of From/
PI from user
of Email::MIME perspective.
And I would propose new module (e.g. Email::MIME::Header::AddressList)
which will be in Email::MIME distribution and will represent list of
Email::Address::XS objects with own implementation of ->as_mime_string()
and ->from_mime_string() methods
On Monday 22 August 2016 22:26:09 Ricardo Signes wrote:
> Here's a verbose form:
>
> # Get an email.
> my $email = get_some_email_mime();
>
> # Get the header -- the (unfolded) raw bytes.
> my $cc_hdr = $email->header_raw('Original-CC');
>
> # parse it into an object
> my $cc_obj
* p...@cpan.org [2016-08-20T06:01:16]
> Email::MIME is module which automatically do any MIME encoding/decoding
> without user interaction, so that decoding must be done automatically
> and without such "upgrade" function.
So do you mean that whenever someone reads the header with a specific
Hi!
Now after long discussion which started 3 months ago and not finished
yet about Email::Address::XS support in Email::MIME I started to writing
code... I want to have something working, usable and not never-ending
discussion.
I implemented new module Email::Address::List::XS which provides
* 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
s 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 Em
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_em
g 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 con
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 obje
* 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
On Saturday 28 May 2016 22:33:02 Ricardo Signes wrote:
> > Thanks to named group support I would like to extend Email::MIME
> > module to allow passing directly Email::Address::XS objects, not
> > only string headers to make MIME encoding and decoding from
> > applications
* p...@cpan.org [2016-05-23T13:05:39]
> I created new perl module Email::Address::XS for parsing and formatting
> email groups or addresses. Parser is borrowed from dovecot and that part
> implemented in C/XS.
Cool!
> Thanks to named group support I would like to extend Email:
Hello!
I created new perl module Email::Address::XS for parsing and formatting
email groups or addresses. Parser is borrowed from dovecot and that part
implemented in C/XS.
Source code is currently at:
https://github.com/pali/Email-Address-XS
Email::Address::XS has backward compatible API
18 matches
Mail list logo
