Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Email-Send CPAN distribution.

Report information
The Basics
Id: 19732
Status: resolved
Priority: 0/
Queue: Email-Send

People
Owner: Nobody in particular
Requestors: rjbs [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: improve plugins: object mailers, mailers outside of Email::Send::
Date: Tue, 6 Jun 2006 09:00:49 -0400
To: bug-email-send [...] rt.cpan.org
From: Ricardo SIGNES <rjbs [...] cpan.org>
(This is an RT-ified version of a patch I originally sent Casey in February of 2006.) I've been agonizing, today, over whether I think I can convert pretty much all of my Perl mail sending to Email::Send. I feel like Email::Send is a little bit naive -- but I've been spending some time trying to decide how much the naivete is the default plugins, and how much is the Email::Send interface itself. It's fine that Email::Send::SMTP behaves the way it does, if I can write one that does what I need. I think what will happen is that we'll define a mailer API to which all our plugins will adhere, and that will be good enough. I'm excited to do this, because my internal mail handling is really not homogenous enough for my tastes, and I think that Email::Send is /probably/ a very good framework for doing what I need. In testing out some ideas, I've run into two related problems, with one solution. 1. I can't use a module outside of Email::Send as a plugin. The docs say I can, if I use the full module name, but testing showed otherwise. The problem is that only modules in the plugin list were considered, and that list is build by Module::Pluggable. 2. I can't use an object as a mailer. This is probably not something that everyone will need, but it will allow me to create many different instances of similar mailers easily, and to have them used more than once by multiple senders. We have a module that does SMTP sending, using one host, but does not disconnect between messages. It is fork safe, disconnect safe, and pretty darn robust. I could create one mailer object and pass it to two sender objects. Yeah, I could implement this by doing some memoization of mailer_args to objects, but... let's not go there. I've attached a patch that addresses these. It includes code and tests, and all tests (apart from some Sendmail tests that I can't run) still pass. It adds a new private method, _mailer_invocant, which returns what should be the left-hand side of the $mailer->send call. If the mailer appears to be a package, it requires it (checking first whether it's the short name of an Email::Send:: module). If it's blessed, it returns it intact.

Message body is not shown because sender requested not to inline it.