Under Construction

Click here to view anyways
  • Previous Page

  • Table of Contents [Show]


    Inbox

    This functionality is exactly what it sounds like. When I receive a message, a copy is sent to me as an email. It, of course, uses a special mailbox but I run my own mail server, so I have the VoIP service whitelisted to guarantee delivery and reroute the mail wherever I like. Of course, if reply from any of my email client, that reply will be sent out as an SMS.

    Online Archive

    I also have my emails archived using my spam filter, so if my mail server is down I can still reply from there and I can even enforce filtering rules if I feel like it. If I don't want texts from area codes other than my own I can just block them, for example. Of course, that doesn't stop them from making it to my phone, but I don't actually look for messages on my phone very often.

    IRC

    The great thing about email is that it just lands as raw text on the mail server. You can do absolutely anything you want with raw text, so this is where it gets nerdy. My favourite way to answer text messages is IRC. I got addicted to IRC at the office where we use it for everything: generating support tickets based off of caller display, alerts for new email tickets, vacation schedules, meeting and call reminders, and just to chat and ask questions. As a result, I always have an irssi window open and have alerts set up whenever my nick is mentioned.

    This allowed me to simply set up procmail to send messages to a special IRC channel mentioning my nick so that I get a notification in the corner of my screen when messages come in. Procmail actually runs a script that creates, or retrieves a nick for each phone number before sending the message to IRC. The nick is made up of a 3 character shortcut plus the actual phone number. That way I can tell who it was from and reply by referencing the shortcut as shown in the image. I have an IRC bot that then parses for the shortcut, finds the associated phone number and sends the message back to it as a reply via email. This way I can have multiple conversations going in the same window, only visible to me, and can reply to each seperately.

    My IRC channel is open from anywhere, but password protected outside of my LAN, so as long as my firewall is open and I have an IRC client, this is usually how I 'text'. The fallback is then my desktop email client. If that fails there is always webmail. If my mail server is down I can use my Archiver. Finally, if I don't have access to a keyboard, I can be an animal and answer with my cell phone, but what am I, some sort of Millenial.

    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 I'm work with email so it was a very easy way 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 like.

    This largely just simplified how I get the data. Most of the user interaction is the same. While the emails still come in, it no longer relies on hitting 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 extremely easy to work with. As email I needed to parse the headers. If messages came in quicker than the program could run I would sometimes get alerted to the first second message twice, and all of this made it slightly slow. The messages in JSON cannot be confused with one another, there is no extra junk to slow it down and the data is guaranteed to be exactly what I was looking for.

    Because it is so much easier to work with and 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. It also tells me if I need to get to work a few minutes early, and checks the forecast to see if I should bring an umbrella or bike to work. 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. Keep an eye out for a future Projects article on this. 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 use it to get OC Transpo bus information.

    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 the comfort of my keyboard.

  • Return to journals list

  • Programming: 'Dealing' with Computers