A History Lesson

In the beginning, there was Internet Relay Chat (IRC). Early on, IRC was enhanced with private messages (PMs). Following this, Instant Messaging (IM) services were born. People were talking to one another instantly and for free online via their computer. Everything was grand. But the underlying basis of each of these technologies was that the recipient of a message was actually online at the moment that the message was sent. Many IM services still do not support offline messaging (or, storing received messages for a user on a central server until they sign on). Now that we expect our technology to follow us everywhere all of the time, sending messages to our pals while they’re not particularly “online” has become a higher priority.

Wait a Second… Why not just use Text Messaging (SMS)?

There are a plethora of arguments for and against text messaging, but right now what it comes down to is preference¹. When it comes down to it, text messages and IMs are fundamentally the same: short messages sent from one person to another. In my mind, text messages ought to be made redundant by things like mobile IM applications since the underlying technology there is inherently more powerful, scalable and flexible.²

The Holy Grail

Alice and Bob both have IM accounts with the fictitious IM service Shoot. Alice pops on her computer to send a message to Bob, but Bob isn’t at his computer. Not to worry; Bob has installed an IM client on his phone and can receive Shoot messages anywhere. Alice sends a message to Bob via Shoot, who receives said message on his phone. Bob’s phone beeps, vibrates and generally interrupts his concentration until he has replied to Alice’s message. Alice can rest assured that Bob got the message, and Bob now knows that he has to pick up Charlie from soccer practice. Lovely.

Not So Fast…

The underlying assumption in the scenario above is that Bob can receive a message over the internet via Shoot anytime because he’s always “online” through his phone’s data connection. Sure, it would be simple to assume that Bob’s phone has a persistent connection to the Shoot servers, but that would be horrible (and unfeasible) from several technical standpoints. Definitely one of the more pressing technical concerns involved is battery life. Unfortunately, keeping an internet connection alive between a phone and an arbitrary server is a bit of a power drain for mobile devices, not to mention the networks they use. But even if we had magical everlasting Willy Wonka batteries, the reality of the matter is that the omnipresence of cellular service just can’t be counted on.

But how, then, do we receive phone calls, you might ask. Doesn’t that require a persistent connection of some sort? Well, yes, it does. But that type of connection is fundamentally different than an internet connection. It’s a direct³ connection to our cellular carrier using a connectivity mechanism crafted especially for making and receiving phone calls and very short data items. They aren’t based on the same type of connections that internet traffic is.

This is where iPhone push notifications come in to the picture. Instead of keeping a connection open to each of our services (Shoot presumably being just one of many), we instead use the existing persistent connection that we keep with our carrier (or one just like it) to bother notify us when something of interest has happened. That way, when Shoot processes a message from Alice for Bob, it forwards the message on to Bob’s carrier, who lets Bob know that there’s a new message. Of course, it’s all a bit more complicated than that, but the basic gist is there.

Now that we have push notifications, what’s the issue? Basically, Shoot doesn’t know how to talk to Bob’s carrier. In fact, all Shoot knows how to do is talk to programs that speak its proprietary (or at least specialized) Shoot protocol or language. Likewise, Bob’s carrier speaks its own specialized language. This means that there needs to be some bilingual middleman somewhere to act both (a) as a Shoot client speaking the appropriate language to the Shoot servers and (b) as a client of Bob’s carrier, sending the appropriate message in its respective language. Oh, and operating such a middleman service costs money. In some cases, big money: more connections, or longer connections, equals higher cost.

So How Does Beejive Do It?

Beejive, like any third-party IM client for the iPhone, relies on a middleman service to relay messages from the various IM services it supports to the phones that are connected to it. This service sits on an internet-connected server somewhere and maintains at least one persistent connection to each IM service for each user that’s “online”. As far as the IM service provider (in our case, Shoot) knows, this middleman is actually an extension of Bob: it looks, feels, tastes and smells just like Bob’s desktop IM client. Beejive has to cover the cost of said service and is presumably doing so by charging a purchase fee for their IM application.

Discussions about one-time-fees versus subscription-model for services aside, Beejive has decided to lower their costs a bit by limiting the amount of time during which its relay service is active for a particular user. At time of writing, this limit is currently user configurable up to a maximum of 24 hours after you last use the Beejive IM application. In short, this means that Beejive IM will log you out after 24 hours disuse. For losers like me who don’t necessarily receive an IM while away from their computer once a day at least, this is a pain. More than just a pain, though, the prospect of being automatically disconnected from a communications service seems stupendously silly to me. Imagine having your phone disconnected unless you make a call every day!

Is There An End To This Madness?

The key issue here — the real reason that we require a middleman at all — is that IM service protocols and standards really haven’t changed a whole lot in the last decade. Sure, we’ve had developments here and there but even still the most popular IM service providers rely on proprietary technology to get their job done. Today’s IM services don’t readily support the type of extensibility that would be required in order to implement middleman-free (or at least middleman-minimizing) mobile instant messaging.⁴ As usual, it boils down to a standards and agreements issue. Until IM service providers pony up with updates to their protocols and services that everyone — ranging from service providers to carriers and clients — can agree upon, we’ll have to continue to use these middleman services, transparent as they may be.

1. Preference for or against text messaging may or may not have anything to do with cost.
2. A bold claim, but this is definitely feasible and even likely. As IM services coupled with social networks become more popular, text messaging usage will inevitably decline. The flexibility afforded by placing more technology in the hands of the community rather than in the hands of cellular carriers will easily trump the straightforwardness of managed technologies like text messaging.
3. Except while roaming, of course, in which case the connection isn’t quite direct.
4. Not necessarily true, but this type of mobile instant messaging hasn’t become standardized or widely implemented yet.

Last weekend, I competed at the 10th Annual Holy Cross Ballroom Dance Competition with Kailee (Standard events) and Brittney (Latin and Smooth events). Altogether a beautifully run competition, as usual, competing at Holy Cross was a lot of fun. In addition to the dancing itself, there was a photo shoot session in which I posed with Kailee. As for placements, it was a very fruitful competition for us. Read on for full results.

Results

Since no detailed results are available, the following chart simply lists placements. If and when detailed results become available, I will update this post.

The Schedule

This competition was particularly difficult schedule-wise. It was bad enough that Harvard booked their competition over the date that Holy Cross had chosen well in advance. What made things worse was that I had decided to attend both competitions — on the same weekend — for as many events as possible. This left me with Latin, Standard and Smooth events at Holy Cross on Saturday. I skipped Rhythm at Holy Cross — which is why you don’t see any results for that style in the chart above — in order to be able to catch the championship rounds at Harvard (always a great demonstration of talent) as well as the showcase there.

Unfortunately, I have noticed that separator bookmarks (-:-) do not appear as menu item separators within the bookmark menu anymore. I have no doubt that this functionality will return soon in a future update.

The Events

Kailee and I were able to compete all of the International Standard events offered in the silver level. Four standard dances were offered as two double-dance events in our level, and we did fairly well in the Waltz/Quickstep event but fell quite short in Tango/Foxtrot. I do feel that Kailee and I have had some productive Standard lessons together with Mark Sheldon, and I can’t be happier with how those lessons have gone. Kailee was ecstatic with the results.

Since I was able to stay through the second style, Brittney and I were able to compete together for the American Smooth Events. One double-dance event and one single event was offered in silver, and we performed better than expected in both given our minimal practice and zero lessons together. Brittney was thrilled to celebrate her first ever Silver Smooth points.

Unfortunately, since I had to get to the airport on time with the appropriate preparations beforehand, I was unable to stay for the American Rhythm and International Latin styles and also missed the showcase.

The Results

The Surprise

In between the International Standard and American Smooth styles, BU announced a competitive fun dance: reverse role Rumba. Tracey and I decided to compete together, and actually placed! Tracey led a great few rounds of American Rumba and apparently I can indeed perform reasonably well as a follower in said dance.

Initial Setup

To get things started, pretty much everything worked out of the box in so far as what was advertised — the Philips universal remote never advertised explicit compatibility with my IR receiver. On the other hand, I had it controlling both my TV and sound receiver in under five minutes. Likewise, once I found out which driver to use with my USB IR receiver, LIRC was very straightforward to configure.

The Problems

As it turns out, there was no device code in the Philips documentation for Microsoft Media Center Edition remote compatibility, so I was on my own. I tried using the learning feature of the remote with mediocre results. Sure, it would eventually learn and reproduce given IR codes but the lag time associated with learned codes on the remote was astonishingly bad. Not to mention that pressing and holding a button was out of the question with learned codes. Try scrolling through hundreds of movies that way.

The Solution

I was able to find a preprogrammed mode for the universal remote that actually made independent use of [almost] all of the buttons on there, and put the remote into that mode. As it turns out, such a mode for the Philips universal remote is the for the ReplayTV DVR. Then I taught LIRC to understand the codes out of that mode using irrecord.

The Outcome

Perfection.

Here’s how to get Fring to work with SkypeOut: prepend the call number a + followed by the country code of the recipient of the call. For example, when calling a phone in the U.S. add +1; (800) 867-5309 then becomes +18008675309. To get the +, I simply press and hold the 0 key on the dial pad in Fring.

I’m not sure that this was always required, as I could have sworn that Fring used to ‘just work’ most of the time, but maybe I’m mistaken. Either way, I’m glad to have it working again!