develooper Front page | perl.pep | Postings from August 2016

Re: Email::Address::XS

Thread Previous | Thread Next
August 25, 2016 07:40
Re: Email::Address::XS
Message ID:
On Wednesday 24 August 2016 22:55:05 Ricardo Signes wrote:
> * [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 to call some "downgrade" function 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 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 others.
> I don't understand "you have no idea about arbitrary object."  Obviously you
> would get a type of object based on the header in question.

Then you need to create mapping from header name to object name. Plus
this does not solve problems for extended/application specific header
(X-Something) which can be used for type which application wants.

> > Anyway, lets move forward. I already implemented something and send
> > information in email with subject "Email::Simple & Email::MIME with
> > Email::Address::XS" to pep mailing list...
> > 
> > I think this is good approach to provide usable API + ability to extend
> > code for other objects...
> This reads like, "Look, just use the API that you don't like because I already
> wrote some code."  That's not going to sway me.

It is not like it...

I would rather know what is wrong with it? And which part? Both
Email::Simple & Email::MIME? Or only some subpart of it? And both
getting and setting headers? Or only getting them?

Do not take me wrong, but to check that API is usable, you need to
implement at least some POC and try to use it yourself. If it does not
meet everything needed, then you need to rework it. And this is what now

And I thought we discuss about it for a long time without trying to
implement something.

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.

> What happens when someone wants a Date object for the Date header?  Do we add
> header_date?  Then header_rcvd for Received headers, and so on?  This interface
> leads to either a proliferation of these things or to some line where we say,
> "well *these* headers are important enough and *these* are not."  On the other
> hand, a generic mechanism is generic.

Hm... here we are dealing with problem: I want header XYX from
Email::MIME, but I want it as object of class ABC. Right?

So easy extensible API needs to have one method which do that. Now I
have only idea with something like this:

 my $addrlist = $email->header_to_obj("Cc", "Email::Address::List::XS");

That will convert header "Cc" to object Email::Address::List::XS and
MIME decode parts which needs to be decoded.

(Maybe class name could be optional and some mapping table for most
common headers could be prepared)

That method still needs to be know how to MIME decode object

But fill free to propose something different/better for this problem.

> You can always publish your work as a subclass, if you think it that popular
> acclaim will convince me I'm wrong.

I would rather fix it, instead creating fork or subclass.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About