A Perl Object Oriented API to send email using Amazon SES using an HTTP persistent connection.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
Net/Amazon
README.pod

README.pod

NAME

Net::Amazon::SES

DESCRIPTION

This module is based on the work done at:

http://aws-catalog-download-files.s3.amazonaws.com/AmazonSES-2011-10-12.zip

Except that:

  • There's an OO API

  • All it does is send email

  • there's really only one public method

    Other than, new, you also have, send_msg - guess what that does?

  • A persistent connection is used

    This is done simply by reusing the LWP::UserAgent object internally and passing the, keep_alive paramater.

I am sincerely no wizard of network programming and this is my first stab and making this work out. It's uncertain if this hack is all that you really will need to make this all work.

Let's see!

REASONING

The included tools for Perl that can be downloaded from Amazon for SES:

http://aws-catalog-download-files.s3.amazonaws.com/AmazonSES-2011-10-12.zip

Are somewhat lacking. The command line tool and the functional SES.pm module aren't very flexible and the coding style is somewhat awkward - I'm not sure if Perl is the author's primary scripting language.

My clients are running into performance problems of piping to a outside script and having that script create one connection per email sent. The speed at which emails can be sent is around 1 message/second.

So, this is my attempt to create a Perl Module with an OO API that does a few things:

  • Simplifies the API

    Piping to an outside command is simple enough, but not very efficient. I wanted to replace that, but still have something simple to work with.

  • Allows you to use a persistent HTTP connection, instead of one connection per email message

Code Status: Ugly Hack

All code is very much in alpha and is based very closely on the original, SES.pm module. It's currently at the status of: Ugly Hack, so don't look for beautiful code.

Real World Performance

Calling the module directly, using a persistent connection and not piping to the ses-send-email.pl script will show speed ups of delivering mail to the Amazon SES web service by around 200%. In my tests, that means each message takes around .3 second to post. It seems the overhead of each connection is around .3 - .6 seconds - and that's what you'll save with each message sent.

API

use Net::Amazon::SES; 

my $ses = Net::Amazon::SES->new(
        { 
                -creds => $path_to_amazon_creds_file, 
        }
); 

$ses->send_msg(
        { 
                -msg => $my_email_msg, 
        }
); 

# Or, send a few messages
foreach(@pre_created_msgs){ 
        $ses->send_msg(
                { 
                        -msg => $_, 
                }
        );              
}

You can certainly disagree with my sense of style, but I thought the above was a little more elegant than what the original ses-send-email.pl gave you.

new

new currently takes one paramater, -creds, which should be the path to your AWS Credentials file

The, -trace paramater may also be passed. If passed with a value of, 1, the module will carp into whatever is set up to receive STDERR. Handy for debugging.

The, <-encode_utf8 paramater may also be passed. If passed with a value of, 1, the message you pass will be encoded with the UTF-8 character set in mind. This is the default. Passing a value of, 0 will disable this encoding, although I do not know why you would do such a silly thing.

send_msg

send_msg currently takes one paramater, -msg, which should simply be the email message itself, as a string. Something like:

From: you@example.com
To: me@example.com
Subject: Test Message!

We did it! It works!

Will do, just nicely.

returns the response code and content.

Please Help!

I can't be the only one that has this same problem and I would love people to help out. Fork and Request Pulls! Please! I am also in no way committed to the name of this module and am in no one ready to submit this to CPAN under its current Ugly Hack state.

Thanks!