Table of Contents [ Show]
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.
