Federation Protocol -- it ain't just Google servers anymore

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Kipp Elliott Watson's picture

Google Wave has been generating a lot of excitement among Drupal developers and there are very good reasons for this. Back in July 2009 or so a handful of Drupalistas, including myself, were privileged to play in Google's Wave Developer Sandbox. In early October 2009, a public preview server was opened to allow many more developers an opportunity to kick the tires on this new vehicle of communication. Most people checked it out for maybe an hour or so, liked what they saw and then moved on to other business. Here in Drupal Wave land some of us demonstrated how to actually embed a Google Wave on a Drupal website (see http://wave-samples-gallery.appspot.com/about_app?app_id=18009 -- also see http://wave-samples-gallery.appspot.com/about_app?app_id=18013). But there was a problem with these early experiments. These were not truly public experiments. Participation in these embedded Google Waves are only available to people who already had access to an account on Google's servers. As months went on, hackers put together a variety of gadgets that allowed Google Wave generated html to be placed, stored, blogged or archived on outside websites (one example is http://www.waverz.com/), but none of this truly afforded full public participation in a Google Wave. They were all tethered to the Google Developer Sandbox or Google Preview Server, which, by the way, to this day do not allow the sending of waves from one to the other.

Drupal developers should take note that all of this is about to undergo a fundamental change. Google announced at the outset, when Google Wave was first introduced, that it would develop a protocol which would allow the hosting of Google Waves on third party servers. In other words, it ain't just about Google servers. It is about the eventual mass adoption of Google Waves as a central means of communication. On November 2, 2009, Google announced the opening of its Federation Protocol port on the Google Wave Developer Sandbox (http://groups.google.com/group/wave-protocol/browse_thread/thread/96e7c6...). As stated by Dan Peterson:
"Just a little bit ago we opened the federation port for Google Wave's
developer instance, so we can all begin experimenting with federating waves
against WaveSandbox http://wavesandbox.com/.com http://wavesandbox.com/.
Since that is the developer preview instance, please keep in mind that it is
an experimental service, and it is likely that there will be unforeseen
glitches in the coming weeks. Please share your progress here in the
wave-protocol forum, so we can work through issues together. "

Excuse me for my soggy language, but I can't help but be reminded of the biblical injunction: "Go forth and multiply." This is, IMHO, a magical moment in the information revolution that, for reasons that perplex me, has been spared the blare of trumpets by the social mass media. Just what does this have to do with Drupal? Technically speaking, Google Waves can now be hosted on third party servers that host Drupal websites. This is not a trivial feat. If embedding a Google served Google Wave on a Drupal website was a walk in the park, embedding a third party served Google Wave on a Drupal website is a cross-country tour. If you want to go on this tour, you will need to learn about a few things. You will need to learn about XEP-0114, the Jabber Component Protocol (http://xmpp.org/extensions/xep-0114.html). Ditto for Openfire (http://www.igniterealtime.org/projects/openfire/) and/or Prosody (http://prosody.im/). You will need to learn about Operational Transforms (how do you handle document states when numerous participants are entering and deleting characters all at the same time within a limited usage of bandwidth?)(http://en.wikipedia.org/wiki/Operational_transformation). I'm assuming you already know enough Java to get by. Python could be helpful too, but if you know PHP well you can pick up Python in a couple of hours. To pull the source for Google's Federation Prototype Server, you'll need to know a version control system like TortoiseHG (http://tortoisehg.bitbucket.org/). And, of course, you'll need to refer to Google's installation guide: http://code.google.com/p/wave-protocol/wiki/Installation.

In terms of setting this up on a local server (http://127.0.0.1), all of this is pretty straightforward. But what about getting Drupal Wave to function on a hosting company like godaddy.com or domainsidekick.com? This is fraught with a lot of technological challenges and it may not be immediately possible. For now, it may be necessary to go with a dedicated server. The main reason for this is that hosting companies control the programming languages that can be used on their servers and XMPP protocols tend to rely on languages like Java or C. Developing a Drupal module at this point entails providing the means by which a portable language can be uploaded to the commercial hosting site, setting up the XEP-0114 compliant communications protocol, configuring the protocol's settings and establishing security certifications. Another approach would be to develop an XEP-0114 compliant communications protocol from scratch using PHP 5. One such project underway is XMPPHP: http://code.google.com/p/xmpphp/.