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.
* p...@cpan.org [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 > did. 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. Okay! 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 special objects.) > [...] > 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 > Email::Address::List::XS... 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 the sentence. Your changes to Email::Simple don't store objects, but produce them on demand. I'm thinking of: https://github.com/rjbs/Email-Simple/compare/master...pali:master#diff-8816e211b9069c6bfa4cc4c82b7410b3R224 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. -- rjbs
Description: Digital signature