2015-07-05 Update

Lately I have been working on a mail server in Groovy.

I have thought about making a mail server for years. The evolution of the idea is this: I decided to run my own mail server, so I went with Apache James. The version I am running is a bit old. The newer version that will be coming out soon is a bigger piece of software. It also handles IMAP as well as POP and SMTP. I looked at it a while back. I am running on a small VPS. I don’t know if I could run something too big.

So I decided to try doing it myself. Let’s see how simple SMTP is.

Turns out it is a bit hard in some places. Right now I am getting bogged down in regular expressions to validate email addresses. There is a class in Apache Commons that handles that. But the problem with using any of the sub-projects in Apache Commons is that you wind up having to download a whole bunch. Like commons-logging, commons-beanutil, commons-io, commons-kitchensink and commons-baggage.

I am writing it in Groovy. I was hoping to try using GPars, but I might not need to. Some of the GDK extension classes, like java.net.Socket and java.net.ServerSocket take closures for arguments, and they run each closure in a separate thread.

I am doing a lot of meta-programming. Mostly I am adding methods to the String class. I am making methods like “isGreaterThan255Char” which just checks if a String is more than 255 chars, and methods that check if a string contains or starts with a particular substring. It is more lines of code, but I think it makes things easier to read. After Groovy Validators, I decided to try some easier meta-programming.

I am also going to use Postgres for the database. I might even use it for tests. I know some testing purists say your tests should never touch the database. Good for them. Never argue with a purist. They will always find something to complain about. What’s wrong with touching the database? I am not using some external data source. I figured I can learn more about mocking and stubbing later. Applications change databases, not mocks and stubs, so why if you never test against a database, what are you really testing?

There are a lot of people in the Chicago Ruby community who are big on automated tests, never touching the database, and making sure their tests run fast. Good for them. But now, looking back, they all seem pretty hilarious. There is a lot of code in this world that has no automated tests at all. If telling people it’s okay to touch the database brings more people into the world of automated testing, then that is a good thing.

You’re welcome.

Image from “Evangelia”, an 11th century manuscript housed at the Bibliothèque nationale de France. Source gallica.bnf.fr / BnF; image assumed allowed under Fair Use.

There are 496 words in this article.