Front page | perl.pep |
Postings from September 2016
From: Ricardo Signes
September 3, 2016 22:25
Message ID: 20160903222456.GA22183@debian
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 all week" week,
but maybe the week after things will even out for a while.
* email@example.com [2016-08-25T03:40:20]
> On Wednesday 24 August 2016 22:55:05 Ricardo Signes wrote:
> > 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.
Yes, you need that mapping, and you extend it on an application-specific basis.
> > This reads like, "Look, just use the API that you don't like because I
> > already
> It is not like it...
I apologize, this was an impolite response.
> 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?
What I meant was: we were talking about questions of API design, and you moved
to implementation, which I think is premature.
> 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
I agree that you need to test an API to determine whether it is sufficient, but
it's also possible to see something is insufficient before trying. Since I
don't think the header_addrlist API is sufficient, it seems like implementation
is jumping the gun, to me.
> 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.
First, I think we should just leave Email::Simple alone. In general, I think
the cases for using Email::Simple are very few, and almost nobody should ever
use it. Giving it new and ostensibly MIME-related features seems unnecessary.
Having said that, I'm not going to look at the Email::Simple changes in depth.
(We definitely don't want to make installing Email::Simple require loading
Email::Address::List::XS, I'll note.)
I think that ->format is probably not a great name choice, as it might exist
other places too easily. For example, Email::Address has a ->format, but I
don't think it will be suitable for this, as it doesn't encode properly. This
is why I originally suggested something almost guaranteed not to clash, like
->as_mime_header. We can assume that programmers won't have to call this very
often, only the innards of Email::MIME, so it's okay if it's a bit wordy.
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 and pointers to bad modules.
Primarily, I don't like the special weight given to the addrlist header. While
it's likely to be the most common one, I think that implementing it as a
special case rather than an application of the general case, is going to lead
to problems. (Just yesterday I spent much of the day on DKIM, and it was clear
that Authentication-Results and Domain-Signature could both usefully have
> 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)
I think this is all plausible. The parts that are important to me are:
* objects working for all headers equally well
* a registry of common field-name-to-class-name mappings
> That method still needs to be know how to MIME decode object
I'm not sure what you mean, here. Do you mean that if we've stored a header
entry as an object that has an as-mime-encoded-string method, we also end up
needed a means to get it as-decoded-string? I'm afraid I just don't understand
Your changes to Email::Simple don't store objects, but produce them on demand.
I'm thinking of:
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 objects,
which are immediately asked to encode themselves for storage
* add header_as_obj that takes a header name and, optionally, a class name and
offset (an offset so you can ask for an object of the nth Received header)
* a registry used by header_as_obj to get a default class name from header name
The downside is that if you call ->header_str(...) for something structured and
there's no registered class for that field name, you get a less than stellar
answer. Really, header_str becomes an odd method, because many headers aren't
meant to exist as unencoded single strings, but are structures. Still, we can
fake it as needed, advising people to consider using object forms directly.
I think the way that header_addrlist and header_addrlist_raw behave is
confusing. Rather than have two object representations, it seems that the data
should be represented as the same object, either way, and then data within it
should be asked for in encoded or decoded format. That is: the header's raw
content is data that classes exist to interpret, access, and produce. If we
generalized this to header_valueobj and header_valueobj_raw, I think it would
be quite bizarre.