concordia-publishing-house/email_relay — pull request #1 by boblail (2014-03-27 22:08:21+00:00)
Title: (wip) Rewriting the Email Relay using the parent / child-worker model

EmailRelay now works by assembling several components:

- `ImapMailbox`: can read messages from an IMAP inbox
- `MailboxWatcher` takes a mailbox and an email handler; it checks the mailbox every so often and dispatches emails to the email handler.
- `ForkingEmailHandler` takes another email handler; it forks a child process to invoke the other email handler
- `EmailRelayer` takes a recipient resolver; it asks the recipient resolver to turn the email's recipient into an array of email addresses; it then copies the email to each of those addresses
- `ApiRecipientResolver`: parses an identifier out of the mailing list address and asks Members or Unite who the recipients should be.

Notice that there some invisible roles:

- `ImapMailbox` is a specific kind of Mailbox — any class than can enumerate emails can be a Mailbox.
- `ForkingEmailHandler` and `EmailRelayer` are both kinds of Email Handlers — any class that implements `handle_email` is an Email Handler.
- `ApiRecipientResolver` is a kind of Recipient Resolver that happens to invoke an external API.

Here's what I've got left to do:

- [ ] Test that `MailboxWatcher` calls `check_for_email` every _N_ seconds
- [ ] Extract a logger from `ForkingEmailHandler`
- [ ] Figure out when emails should be deleted and where the concern for that should live; test
- [ ] Handle errors (possibly just by logging and crashing)
- [ ] Daemonize the relay
- [ ] Finish the Integration test (involves designing configuration)
- [ ] Figure out how to deploy (and restart) Email Relay
- [ ] Figure out how to ping Email Relay to see that it's alive