IME/pull/35
> >
> > Done!
>
> I have there open question about header_to_class_map. Can you look at
> it?
And last part which implements Email::Address::XS support in Email::MIME
via new module Email::MIME::Header::AddressList is in this pull request:
https://github.com/rj
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:
>
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?
* 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
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:
> >
> > * al
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
> o
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
> o
that 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!
uses Email::Address for generating those
> > header values (which is broken) and then 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
> > h
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 the r
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 value
It is OK for you?
That all sounded fine. I think the paragraph I left quoted overspecifies a
bit. Whether the object is storing things decoded or not isn't any of our
concern as long as it has those two methods. But I think we're on the same
page.
The Email::Address::XS use should be
r Email::MIME API 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_s
* 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 cl
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
* 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
don't think it will be suitable for this, as it doesn't encode properly. This
For Email::Simple it is correct. And for _raw functions in Email::MIME
too. ->format from Email::Address (and also Email::Address::XS as it is
replacement) correctly generate that header. But it expect t
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
; structure, and it provides methods that answer the questions one needs to
> > > ask.
> >
> > Because you have no idea about arbitrary object. If you want to e.g.
> > decode Email::Address::XS object, you must decode only ->phrase() and
> > ->comment() parts!
ction and
> > > then "upgrade" it to another object or so...
> >
> > Why would this not be possible? There is some object storing the mailboxes
> > structure, and it provides methods that answer the questions one needs to
> > ask.
>
> Because yo
* 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
that
ere is some object storing the mailboxes
> structure, and it provides methods that answer the questions one needs to ask.
Because you have no idea about arbitrary object. If you want to e.g.
decode Email::Address::XS object, you must decode only ->phrase() and
->comment() parts! Not oth
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 met
* p...@cpan.org [2016-08-18T17:35:10]
> On Thursday 18 August 2016 23:21:28 Ricardo Signes wrote:
> > As you say, 1 and 2 are dealt with. For 3 or 4, you want to have an
> > object in the header slot, rather than a string. Once you've done
> > that, you use its methods. If the object's To field
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
o: field
> > >
> > > 2) Unicode string representation of To: field
> > >
> > > 3) List of Email::Address::XS objects which are in To: field
> > >
> > > 4) List of named groups with Email::Address::XS objects of To:
> > > field
> >
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
> >
.
The only difference between header and header_str, I said, would be how they
treated plain strings.
> 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
>
d of
> object I proposed above for passing a raw header into header_str.
> Headers set with header_str get the kind of thing that mime_encode()
> returns. Possibly/probably if you have set the From header with
> header_str, you get the object currently being produced, just for
>
* 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 not say it needs string.
People will want to be able to pass non-AS
On Tuesday 02 August 2016 01:00:02 Ricardo Signes wrote:
> * 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
* 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 take
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 i
x27;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
ng the header, the code will do something like:
>
> $string = $name . ": "
> . ($value->DOES('Email::MIME::Header::Value')
> ? $value->as_mime_header
>
> : "$value");
>
> No existing object
t;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");
N
t magic is used then it will not be such easy
to check if string value (stringified) or object value is used. So this
is reason why I proposed header_addr and header_grps to make it clear
what you want to pass.
Also it is similar to list/group API of Email::Address::XS module. If
you think that
* 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::MIME
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 with
42 matches
Mail list logo
