On Tue, Feb 20, 2007 at 07:07:43PM -0500, Ricardo SIGNES wrote: > Email::Sender has one main class, the sender. Email::Sender's send method > accepts a message and arguments, canonicalizes the arguments, and tries to > deliver the message. It returns either a "successful delivery" report or > raises an exception.
There's already a Mail::Sender on CPAN... is Email::Sender enough of a
name collision to cause confusion?
Are you planning to define exception classes, or just leave it as a
free-form die q{Failed for some reason};?
For example, being able to throw things like this within an
Email::Sender implementation:
die Email::Sender::Exception::TemporaryFailure->new({
text => 'We got greylisted' });
die Email::Sender::Exception::PermanentFailure->new({
code => 552,
extended_code => 5.2.2,
text => 'User is over quota'});
or
die Email::Sender::Exception::ExecutionFailure->new({
text => '/usr/bin/sendmail not executable' });
might be nice for error handling and recovery. But, it might also be
well outside the scope of what you want to do with Email::Simple /
Email::Sender.
> Specific transports are implemented as subclasses of Email::Sender. Most will
> only override the (virtual) "send_email" method that does the sending. It
> will
> always receive an Email::Simple-like object and arguments including "to" and
> "from" to be used in transporting the message.
Providing an envelope sender and recipient(s) separate from the From/To
headers of Email::Simple is definitely a good idea. Maybe we need an
Email::NotQuiteSoSimple (bad name, but just for discussion's sake...)
that's basically an Email::Simple with envelope_sender() and
envelope_recipients() methods added. They could either be set directly,
or if left unset, would pull their values from the appropriate
$self->header('...') values.
> Because the return value of a successful delivery always has a known interface
> (currently I'm calling it Email::Sender::Success, but something more like
> Email::Delivery::Successful seems better, but also silly), and because there
> is
> at least a small core of guaranteed common arguments, senders can be swapped
> out with a known worst-case level of degredation.
How about Email::Status::Success? Email::Status could be an abstract
base class for the return codes and exceptions as well, specifying a
common API for getting/setting error text and SMTP error codes.
Cheers,
Dave
signature.asc
Description: Digital signature
