When we were first writing the software for LinkedIn, Jean-Luc put together a python script that would act like a dummy MTA and mail store. The point was that the application was going to be sending out emails of various kinds, notably invitations to connect, and we needed to be able to write tests that would verify that feature (the emails are well-formed, they actually get sent, etc.) without sending real messages to real email accounts. This was incredibly valuable.
Years later I was contracting at NASA, working on a system that, again, generated emails. I wanted to institute some kind of automated testing, and tried to come up with a similar tool for use there. I found out that I’m allergic to python but I found a Java program that did half of what I wanted – it would pretend to be sendmail and accept any emails and just stuff them into an in-memory store. I forked it and modified it to add a POP3 server so that the application could generate and send the emails and then a tester could open the email with Outlook or Apple Mail or whatever and then click included links or open attached files, etc.
Even later, I modified that program by putting a JavaFX graphical UI on top, and letting you spin up multiple corresponding SMTP/POP3 server pairs. The point, that time, was that I was working on a play-by-email server and I wanted to have the server and clients all talking to each other via email but still on my development machine. As a responsible software developer, I do not make a practice of turning untested robots loose on the world.
The problem that I have with the program as it stands is, well, there are a few problems. First, it’s in Java; Apple has stopped treating Java like a first-class citizen of the desktop, and it’s getting harder and harder to convince a JavaFX app to build, let alone to act like a Mac app. Second, it takes way too much in the way of computer resources. When it’s running, my laptop gets hot and the battery drops. It’s awesome to have the tool, but it gets like 1 kiloflop per hogshead of diesel. I feel like it should be possible to do better, and I feel like the problem lies in JavaFX. Third, I’m trying to learn Swift and SwiftUI so that I can write native applications. This feels like an opportunity.
In about 1991, someone I knew made a pun around “Ren & Stimpy” being like rn and SMTP and that has stuck with me. So, I’m porting dumbster from Java to Swift, and that involves changing the name. Thus, I dub the new project, “Stumpy.”
One thought on “Stumpy: History and Problem Statement”