Re: Email::Address::XS

2017-03-07 Thread pali
On Tuesday 14 February 2017 21:26:34 p...@cpan.org wrote: > On Saturday 28 January 2017 21:48:55 Ricardo Signes wrote: > > * p...@cpan.org [2017-01-14T15:32:57] > > > > > So lets move. This is implemented in my pull request: > > > https://github.com/rjbs/Email-MIME/pull/35 > > > > Done! > > I

Re: Email::Address::XS

2017-02-18 Thread pali
On Monday 23 May 2016 19:05:39 p...@cpan.org wrote: > 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: >

Re: Email::Address::XS

2017-02-14 Thread pali
On Saturday 28 January 2017 21:48:55 Ricardo Signes wrote: > * p...@cpan.org [2017-01-14T15:32:57] > > > So lets move. This is implemented in my pull request: > > https://github.com/rjbs/Email-MIME/pull/35 > > Done! I have there open question about header_to_class_map. Can you look at it?

Re: Email::Address::XS

2017-01-28 Thread Ricardo Signes
* p...@cpan.org [2017-01-14T15:32:57] > So lets move. This is implemented in my pull request: > https://github.com/rjbs/Email-MIME/pull/35 Done! -- rjbs signature.asc Description: Digital signature

Re: Email::Address::XS

2017-01-23 Thread pali
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: > > > > *

Re: Email::Address::XS

2017-01-14 Thread pali
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 >

Re: Email::Address::XS

2016-11-12 Thread pali
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 >

Re: Email::Address::XS

2016-11-12 Thread pali
On Monday 05 September 2016 10:25:11 p...@cpan.org wrote: > On Saturday 03 September 2016 18:24:56 Ricardo Signes wrote: > > The Email::MIME changes look like they could be broken up into > > several PRs, some of which would be obviously good to apply > > immediately, like removals of dead code

Re: Email::Address::XS

2016-09-30 Thread pali
On Wednesday 28 September 2016 15:29:28 Ricardo Signes wrote: > * p...@cpan.org [2016-09-18T11:40:53] > > > Currently passing string values of From/To/Cc/Bcc/... headers into > > header_str() method is broken in Email::MIME. That is because > > Email::MIME currently uses Email::Address for

Re: Email::Address::XS

2016-09-28 Thread Ricardo Signes
* p...@cpan.org [2016-09-18T11:40:53] > Currently passing string values of From/To/Cc/Bcc/... headers into > header_str() method is broken in Email::MIME. That is because > Email::MIME currently uses Email::Address for generating those header > values (which is broken) and then MIME encode

Re: Email::Address::XS

2016-09-18 Thread pali
On Sunday 18 September 2016 17:26:11 Ricardo Signes wrote: > * p...@cpan.org [2016-09-17T19:05:51] > > > $class->from_mime_string() will take raw MIME encoded string and > > returns new object of $class (which will have decoded string > > parts) $object->as_mime_string() will convert (Unicode)

Re: Email::Address::XS

2016-09-18 Thread Ricardo Signes
* p...@cpan.org [2016-09-17T19:05:51] > $class->from_mime_string() will take raw MIME encoded string and returns > new object of $class (which will have decoded string parts) > $object->as_mime_string() will convert (Unicode) $object into raw MIME > encoded string > > It is OK for you? That

Re: Email::Address::XS

2016-09-17 Thread pali
On Saturday 17 September 2016 00:37:40 Ricardo Signes wrote: > * p...@cpan.org [2016-09-12T03:26:52] > > > And as I wrote if Email::MIME is not good place, then what about > > other modules like Email::MIME::Header::Address (or invent other > > name) which will use Address parse/format functions

Re: Email::Address::XS

2016-09-16 Thread Ricardo Signes
* p...@cpan.org [2016-09-12T03:26:52] > And as I wrote if Email::MIME is not good place, then what about other > modules like Email::MIME::Header::Address (or invent other name) which > will use Address parse/format functions and will also do that MIME > encode/decode procedure? We can maybe add

Re: Email::Address::XS

2016-09-12 Thread pali
On Sunday 11 September 2016 18:58:42 Ricardo Signes wrote: > * p...@cpan.org [2016-09-05T04:25:11] > > I do not want to add ->as_mime_header (or other function) which will do > > MIME encoding/decoding into Email::Address::XS. That module is for > > formating and parsing email addresses headers,

Re: Email::Address::XS

2016-09-11 Thread Ricardo Signes
* p...@cpan.org [2016-09-05T04:25:11] > I do not want to add ->as_mime_header (or other function) which will do > MIME encoding/decoding into Email::Address::XS. That module is for > formating and parsing email addresses headers, not for MIME > encoding/decoding. Same as it is for Email::Address

Re: Email::Address::XS

2016-09-05 Thread pali
On Saturday 03 September 2016 18:24:56 Ricardo Signes wrote: > > Look at my proposal just for first version and lets change parts which > > are not OK for you. I do not believe that everything is totally wrong. > > Okay! > > First, I think we should just leave Email::Simple alone. In general, I

Re: Email::Address::XS

2016-09-03 Thread Ricardo Signes
I know I'm taking a long time between replies. Thanks for being patient. I've been rotating through "out of town" and "catching up with work backlog from being out of town," basically, and in the leftover time, I don't have any brain left for anything much at all. This week is another "all work

Re: Email::Address::XS

2016-08-25 Thread pali
On Wednesday 24 August 2016 22:55:05 Ricardo Signes wrote: > * p...@cpan.org [2016-08-23T03:56:24] > > > > Also it must be possible to get either named groups from Original-Cc > > > > header or only list of addresses. And I think with your proposal API it > > > > is not possible. You would need

Re: Email::Address::XS

2016-08-23 Thread Ricardo Signes
* p...@cpan.org [2016-08-23T03:50:03] > That is really bad API :-( This is the *low level* API which of course the user does not call. They'd want the version of Email::MIME that gives them these header objects on the fly. I suggested there'd be a means to "upgrade" all the known headers so

Re: Email::Address::XS

2016-08-23 Thread pali
On Monday 22 August 2016 22:34:39 Ricardo Signes wrote: > * 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

Re: Email::Address::XS

2016-08-23 Thread pali
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

Re: Email::Address::XS

2016-08-22 Thread Ricardo Signes
* 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

Re: Email::Address::XS

2016-08-18 Thread pali
On Thursday 18 August 2016 23:21:28 Ricardo Signes wrote: > > If I create Email::MIME object from input string, I would like to > > get: > > > > 1) Raw (ASCII) string representation of To: field > > > > 2) Unicode string representation of To: field > > > > 3) List of Email::Address::XS objects

Re: Email::Address::XS

2016-08-18 Thread Ricardo Signes
* p...@cpan.org [2016-08-08T17:41:04] > Here we are need to deal with objects which internally needs to be MIME > encoded and objects which mustn't. I don't think this matters. If an object is passed in, it must be able to produce a MIME encoded form. Even if you say: header_str => [ header

Re: Email::Address::XS

2016-08-08 Thread pali
On Wednesday 03 August 2016 00:36:11 Ricardo Signes wrote: > * p...@cpan.org [2016-08-02T17:03:07] > > > I can imagine, that people could be confused about header_str > > meaning. It has suffix _str and I would expect it needs (Unicode) > > string, not object... Name "header" is better as it does

Re: Email::Address::XS

2016-08-01 Thread Ricardo Signes
* 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

Re: Email::Address::XS

2016-07-12 Thread pali
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 > > >

Re: Email::Address::XS

2016-07-03 Thread Ricardo Signes
* 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

Re: Email::Address::XS

2016-07-03 Thread pali
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

Re: Email::Address::XS

2016-06-30 Thread Ricardo Signes
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

Re: Email::Address::XS

2016-06-01 Thread pali
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(

Re: Email::Address::XS

2016-05-30 Thread Ricardo Signes
* 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

Re: Email::Address::XS

2016-05-28 Thread pali
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 easier. > > > > What do

Re: Email::Address::XS

2016-05-28 Thread Ricardo Signes
* 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::MIME module > to