Example

Suppose you have a class defined as follows:

template <class T> class Foo {};

You might use the class as follows:

/** A Foo pointer with @c int as the template parameter. */
Foo<int> *myFoo;

The comment above is correctly interpreted by Doxygen and, if enabled, will automatically link the text Foo to the documentation for the Foo<T> class.

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.