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.