I'm tired of trying to fix hard-to-fix issues in Email::Send, and tired of
saying, "Yeah yeah, Email::Sender someday soon blah blah."
So, I'm doing a bit more work on it. Here are my current thoughts:
Email::Base is good enough for now. All it does is provide ->throw, which is
enough. Someday, I imagine there will be more to it.
The big thing it doesn't do that we talked about is a generic constructor and
attributes. This isn't a big thing, but it's starting to mildly irritate me as
I work on Email::Sender. I don't want to just "bless $arg => $class", and I
don't want to say, "all guts are available to all subclasses" or "stick your
subclass's guts in $self->{__PACKAGE__}. These all suck.
Also, I've refactored "args for the Sender" from "envelope data." Given a mail
with a "prec" send-time option, this is still correct:
$sender->send($email, { to => $rcpt, from => $sender, prec => 'bulk' });
...but it is turned into:
$sender->send_email(
$email,
{ to => $rcpt, from => $sender },
{ prec => 'bulk' },
);
Now, you end up writing:
sub send_email {
my ($self, $email, $env, $arg) = @_;
...
}
Blech. What I really want is something we've long talked about internally at
work, and something that DaveO and I talked about once or twice at YAPC:
messages with attached envelopes. Email + Envelope = Delivery. The you say:
$sender->send($email, { to => $rcpt, from => $sender, prec => 'bulk' });
...and it becomes:
$sender->send($delivery, { prec => 'bulk' });
If you already have a Delivery ready to go, you pass it to the $sender->send to
begin with.
The way I see it, a Delivery does the Email and Envelope roles. It has-a Email
and has-a Envelope, and delegates the roles to them. This (plus the pair of
fuzzy antler headgear I received for Christmas) is making me start to decide
that I'm going to say "screw it" and use Moose. If Email::Sender is a Moose
object, it becomes very simple to deal with the attribute issues. I also think
(but cannot yet prove) that it will make Email::Sender::Wrapper trivial to do
away with, letting Email::Sender::Failable operate directly on concrete Sender
classes.
I will start work on this in the next week, and it should be very easy. If you
have objections, voice them now.
My only concern at the moment is that I want the Email role to be easy to grow
in the future. I'll spill my guts on some of that now:
I want method naming to be uniform across all of these classes, and I think it
may have to be set/get. Here is why: headers. It is very convenient to say:
$email->header($header_name);
This is also convenient:
$email->header($header_name => $value);
This starts to get weird:
$email->header($header_name => $value, $value2);
This sucks:
$email->header($header_name => undef);
I'm also not crazy about "well you use set to set it to anything except for
nothing, which requires delete." I could be convinced, though. There's always
"setting multiple values requires an array ref, and [] clears." I don't know,
I welcome thoughts on the matter.
There will be a EmailHeader role, I think. I'm not sure how it will work yet,
either. I will probably steal or at least think about stealing from Mail::Box,
which does some cool stuff with how bodies and headers interact.
Ok, this message is now officially too long. I look forward to hearing your
thoughts.
--
rjbs
