Wiki

Clone wiki

cartero / Home

Welcome

Cartero's going to be really cool when it's done.

Senders

Eventually, you will be able to use these senders:

  • SMTPSender - sends mail over an SMTP server
  • AppEngineSender - uses App Engine mail API
  • MailboxSender - drops mail directly in a Maildir/mbox/whatever mailbox
  • XMLRPCSender - calls the 'mail.send' method on a remote server with a list of message structs
  • MemorySender - appends Message objects to an outbox list attached to the sender (for testing)
  • FileSender - saves sent mail to a folder in a human-readable format (for debugging)
  • ConsoleSender - dumps sent mail to stdout in the same format as FileSender (for debugging)
  • NullSender - logs that it got a message, but doesn't do anything [IMPLEMENTED]

Stuff to do

  • Get the MIME stuff working (dumping a message in properly encoded MIME format). Lamson seems to have a pretty good handle on this. This will probably go in cartero.encoding.
  • Write the remaining senders. SMTPSender is highest priority once cartero.encoding is done, and MemorySender and FileSender are highest priority before then. AppEngineSender and MailboxSender will be next.
  • Write a 'cartero-send' script that can send mail from the command line.
  • Write complete documentation and a full test suite.

That will be for the first full release. If there's time, we may also want to look into:

  • A server that accepts the method call from XMLRPCSender and sends the mail somehow else.

And outside of Cartero itself:

  • Get a Flask extension with Cartero working. That way we can demonstrate how easy it is to integrate into a framework.

Stuff to figure out

  • Some of the senders might be kinda hard to test. AppEngine especially, since it requires the whole AppEngine SDK (which in turn requires Python 2.5), but SMTPSender and XMLRPCSender will probably also be difficult since both involve contacting an external server. (Both servers can be implemented from the stdlib, but launching them would be tricky.) ConsoleSender we won't even bother with besides a quick check, since it's not critical.
  • Exception handling in the senders. From a code standpoint it would nice to have exception wrappers that wrap exceptions and tracebacks during the send process (ConnectError for when connecting and SendingError for when actually sending messages) so they can be caught and handled more easily, but I'm not sure how to properly handle tracebacks in that case so they can be correctly debugged.

Updated