X
Business

Android developers fight for XMPP support

In early versions of the Android SDK, Google supplied an implementation of XMPP for peer to peer communication and for an always-on connection for push services. In M5 it was replaced by a Google branded GTalk service, and a number of Android developers are not too happy about it.
Written by Ed Burnette, Contributor

In early versions of the Android SDK, Google supplied an implementation of XMPP for peer to peer communication and for an always-on connection for push services. In M5 it was replaced by a Google branded GTalk service, and a number of Android developers are not too happy about it.

In a thread posted on the Android developers group,  Muthu Ramadoss said:

Lots of developers were excited about XMPP support in Android and were going crazy building peer to peer messaging services for Android. I personally was building a Twitter like service for Android. But with the latest announcement of plans with GTalk going native, many developers like me are forced to fallback on http, rest etc..

Google says that they never intended to provide full XMPP support. They needed some P2P communication for their own applications and decided to expose it in case others found it useful. Since it's always been in the com.google package, it's not considered part of the Android core and thus will not be available on all phones. Google's Dan Morrill writes:

The XMPPService/GTalkService really only has 2 goals:

  1. Provide a way to efficiently send simple P2P-style messages (in the form of Intents) between handsets, and
  2. Provide a way to send and receive IMs using Google's Talk servers.

Originally, we intended this service only for our own use. However we realized that #1 in particular would be very useful to all developers, so we exposed the Service.  (Some developers might be interested in #2 as well, although we don't think simply sending instant messages through our servers is as exciting as the P2P functionality.)  The use of XMPP under the covers was really just an implementation detail, and so you might say it was a bad design decision to have named it XMPPService in the first place.  Unfortunately it caused some confusion as to what the service was intended for, which is why we've changed the name.

Calling this an "amazingly short-sighted decision", forum member Jeff McAdams says XMPP has the potential to be the next big data transport system for the Internet. He was really happy when he discovered it in the SDK but,

Imagine my disappointment when, five days later, the new SDK is released and Google has done a s/XMPP/GTalk/, and then I go and read the explanation and a couple of things become apparent:

  1. This potentially world changing (well, the computing world, anyway) capability came to be basically by *accident*.  Well, ok, there's a long history of inventions, and discoveries happening by accident (penicillin, vulcanized rubber, X-rays...there's plenty more where that came from)
  2. They apparently don't even realize what it is that they've got!
  3. The planned roadmap is gonna absolutely cripple this by playing walled garden games with it. Apparently, because of #2, since the googlefolk don't realize the importance of what it is that they've developed here, they're not considering how important this is to be treated with respect, and they're about to wall it off into a walled garden, not realizing the damage that they're going to do in the process.

Issue 201 has been opened to track XMPP support, though Google has already marked it as 'declined', and suggests that the community write its own API and use that instead of using the Google one, which will become incompatible with XMPP over time.

Why should you care? On the OpenIntents forum, Pele explains:

As indicated here (in the last section on P2P services), XMPP could potentially be used to far more than just a chat client: Applications that live on different Android phones can start to talk to each other quickly and directly without the need of user interaction.

In this way, one can build multi-user games, synchronize shopping lists or central tags, transparently keep schedule changes in group calendars up-to-date, and do whatever you want. You can virtually send "open intents" to another phone - start an intent on another phone: that is basically an rmi call.

Possibilities are endless...

If you'd like Android to have, as part of its core services, a secure peer-to-peer networking capability, then star Issue 201 and add your comments and use cases.

Related articles:

Editorial standards