API

As I mentioned, the SMS to Email interface is largely old news. It is an inelegant way of interacting with the service. There are a lot of steps, but less complicated than doing any serious programming to hack together a solution. I have since taken the time to do this better by interacting directly with the services API. For those who aren't aware, this is a Application Programmer's Interface. Basically it means that I can send requests directly to the service provider and handle the responses however I need. This is how apps like the third-party Android app I use work.

This largely just simplified how I get the data. Most of the user interaction is the same. While the emails still come in for archiving and replying will still work, I no longer do anything with Procmail. Instead, I can have my API program running anywhere I like, not just on my mail server. This is then able to submit new messages directly and poll for any new inbound messages to alert me to. When new messages still come in, the code that sends that message to IRC behaves basically as it did above and IRC replies are forwarded back through the API as well.

The main advantage to the API data is that it is all standard JSON which is a data structure that is extremely easy to work with. Emails are sort of clumsy for things that aren't regular email since they come with large headers. I need to parse the Subject to get the sending phone number, then need to make sure that only the text in the body gets collected as the message, and the rest is useless. Email is also not guaranteed to be an instant communication tool. It is robust so that if a message is delayed it will be retried regularly, but flow through multiple servers, including at least one spam and virus scan means that it could take seconds, minutes, or days. The messages in JSON cannot be confused with one another, because they inclued IDs that can be referenced in other API calls. There is no extra junk meta-data, and no extra steps to slow it down.

While the data is much easier to work with, but developing an API client application is more work. In the end though, because the functions that send and receive the messages are abstracted away from the interface, it is much easier to add new ways to interact. For instance, I have a Cronjob that looks through my calendar and sends me a text message for appointments, such as meetings that I have that day. If I'm away from the office 30 minutes prior, as indicated by my phone not being on the Wi-Fi, it will alert me to get back to the office. I could set up a task to automatically send other people messages on certain days/times. I have even set up a basic auto-reply robot that can provide myself and others with information. For instance, if the sender is on a trusted list, they can find out what I have scheduled by asking the robot. Unknown/untrusted numbers can get pointed to this website. I can text myself to have the bot give me OC Transpo bus information, or add an appointment to my schedule. Keep an eye out for a future Projects article on this robot as I'm working on a new version that will have many more features. This also solves the message filtering problem since the API allows me to delete the messages remotely and my phone will sync those deletions.

Some of this can be cobbled together with Google Calendar and a specific app for each task. Others just can't be done at all. But even with those that can be done, I would be changing from the way I want to interact with the system in order to get the result I want. I don't want Google to know my schedule, nor do I want 30 apps on the phone I rarely look at. If I sit in front of an IRC screen all day anyways, it is nice to get all of my notifications and messages there, where I can react to them with a comfortable keyboard.