I had started this project for two reasons: first, I had another project in mind that needed to access Google Voice; but knew of no way to do so; and second, I wanted to provide a way for developers to easily access Google Voice.

My idea was to access Google Voice's internal API, parse it with lxml and cjson, and keep the results stored in classes specific to the type of data to make utilizing Google Voice in any project a simple thing to do. However, as I was finishing up on a recent change of the conversation class to be Python properties, I decided that it would be fun to do a quick search for "Python Google Voice." I had never done this before and figured enough time had passed due to a number of things (work, school, an accident I was recently in) that it was possible that something did indeed exist.

How right I was. I found a very nicely coded project on Google Code (originally GitHub, it appears) called PyGoogleVoice. Authored by Justin Quick and Joe McCall, I have emailed them to let them know that I am stepping down on my own version. A lot of the features that they have meet (and even exceed, such as stemming the project to support Asterisk) what I envisioned smsGV (now py-smsGV) behold.

I am still going to work on the project that had inspired me to originally create. Though, instead of using my own library, I have decided it proper to use Justin Quick and Joe McCall's. It has been more finely tested, is better featured, and will continue to be updated while py-smsGV will not.

Also, for both the benefit of PyGoogleVoice, should they find inspiration, and other developers, I am going to still post my code to GitHub. It's not as fine-tuned as I would like, it is not representative of my actual skill because certain parts of it are still written in an early 'testing' fashion and had yet to be refactored or rewritten and finalized. However, I'm not a very big fan of just destroying code. Knowledge and inspiration can come from many places, possibly including my code, and so I have no problem hesitating to post it, even in its incomplete stage.

This post is just to let everyone know about the other Python Google Voice project in existence and to keep anyone who had been waiting on mine from anticipating or being anxious. I'll post more about any lessons learned from the coding I had done on this as well as more about the project I had in mind in the (hopefully near, depending on my accident recovery, schooling, and work) future.

Aside from a few new projects and developments for work, I have delayed the release of smsGV slightly (though its commits are always available publicly on GitHub—albeit not very recently updated, that's to be soon changed).

It's only fair that I let you all know the reason for the delay. It's not because I don't love smsGV or Google Voice anymore, I use it daily, but rather because I have traversed the Google Voice backend further and found a more optimized route to achieving my goals. Furthermore, I've found that using it will prepare the smsGV library for additional features that otherwise would not have been or would have been difficult and inefficient to implement.

That's all for now. I just wanted to keep everyone posted on the progress.

The Problem

 

I jumped up and down with excitement when I received my Google Voice upgrade, for many reasons that excite me. First is being able to place calls through the number, and receive calls as well. Though, the most important was by far SMS. I do not have a messaging plan on my mobile because it is just plain expensive, but I do have a data plan on it: for work, for play, and because the price is certainly right.

 

The problem that I have with Google Voice at the moment, however, is that there are two ways to receive messages on my phone through my GV number:

 

1. Receive the message via SMS 

1.  Check via www.google.com/voice/m/

 

Now, given what I have already said, the first option is out right away. So that leaves the option behind door number two – using my browser to check for new messages. Option two introduces an issue that, for me, defeats the whole purpose of SMS: notification.

 

My phone buzzes, dings, and changes the colours on my room’s walls whenever I receive a new email. (Okay, well, it does most of that). Sadly, it does not know when to set off its bells and whistles if the only way that it has to check for new messages is Pocket IE, Opera Mobile, or whichever other browser you prefer. This is an issue, since I don’t want to refresh the browser minutely, or even bi-minutely, to maintain a conversation with a friend.

 

Why not email their number?

 

Sure, you may point out that I can just email theirNumber@carrierSmsDomain.tld. I absolutely despise this method: it is tedious, prone to errors, and it means that I have to dig up all of these carrier emails, know if they change. Overall, it is simply a hassle, and hassles do not appeal to me.

 

Alright, alright. We get it - on with “The Solution”

 

The solution, in my humblest of opinions, is quite a simple one. Why not have Google Voice send new SMS messages to my email? It’s really quite an easy process, something that the “Big G” could implement with ease given they have direct access to the SMS receiving hooks. And yet, they have not. Not for a lack of request from their users, as numerous postings online show. Not from a lack of engineering and programming intelligence, as their Google Wave shows. Perhaps it is simply because the service is new and they do not want to overstuff it with potentially useless features. I truly do not know, I’d have to talk to Larry or Sergey to find out.

 

So, rather than waiting and speculating if the multicoloured giant will ever release this feature, I’ve decided to implement it myself.

 

How?

 

First I had to inspect the Google Voice system to see what potential methods were available for me to use.

 

The basic idea that I narrowed everything down with involves a lovely little friend of mine called Python, a module with the sweet name of “lxml,” and some inspection of the Google Voice system. At the time of this writing, I know what tactic I will be using because, well, I’ve already implemented it. The project is not released just yet because I’m still adding the gravy to my potatoes, but the core of my strategy has been prototyped, written, implemented, tested, and proven. The library uses a combination of Google’s mobile and “full” website, along with parsing the included JSON, in order to most efficiently and accurately retrieve new messages.

 

Password handling.

 

One obvious line of thinking is that I would have to store the passwords. This bothers me, since to make storing them useful I would either have to encrypt in such a way that decryption was swift (which would ultimately only be faux security at best), or I could store them plaintext.

 

“Which way, then?” you may be asking. My answer is quite simple: "Neither." I do not like storing such sensitive data plaintext, and upon further inspection it is not necessary. When the library processes a login request it will store a persistent cookie to ensure that the session lasts for as long as possible. Of course, exceptions where the cookie expires or shows as invalid are handled appropriately.