This past weekend I set out explore some of the extension capabilities of Google Wave. One of the weaknesses that have been identified by many is the lack of integration with email. For me, in particular, because Wave is new, many Waves are being orphaned as those playing and testing out Wave don’t come back to the conversation for long periods, if at all. My goal was to use email as a means to bring people back to the Wave and keep the collaboration/discussion going in a single environment. Some developers are exploring letting users contribute from email, but in my opinion, that undermines the goal of Wave.

First, Kudos to Google for making it easy and straightforward to get a development environment ramped up quickly for developing extensions. Robots are based on their Google App Engine architecture, which allows users to leverage their Eclipse plug-in for App Engine development. For anyone that has ever developed a servlet-based application, the plug-in for packaging and deployment in the App Engine environment made the entire process quick and easy. Of course for fun, I had to set up an Ubuntu instance in my virtual machine environment to do this development.

After getting my environment configured, I downloaded a Java-based Robot sample that is the equivalent of “Hello World!” for Google Wave Robots just to ensure that I could compile and deploy. There was very little effort to make this work and test. Of course, not having a sandbox account yet meant that I had to use production Wave environment, so there’s now a lot of orphaned waves that I used for my tests.

With my application harness up and running, it was time to dive into the documentation and play. In my initial design I was planning on using the Wave itself as a storage mechanism for the subscription registrations, but as I learned, there is no guarantee that a Robot will have access to all Blips—the unit of data within a Wavelet—within a Wave. However, to learn that took a lot of review of the Wave data structures and data received from the Wave server based on the events I was processing. At first, I used the Wave itself to produce the artifacts for review since I was having issues getting my debug statements to appear in the application log. This was not a good idea as the Wave environment couldn’t handle the mass number of Blips being added at the speed the Robot was adding them. So, I had to aggregate the data and then put it all into one Blip. Making use of this data was also interesting since my formatting commands were being ignored. I finally figured out n works in a text blip for a newline, but never got the markup content to be produced properly.

All of the above could have been avoided if Google simply documented examples of what the input to the Robot would look like and described the structure of the data received. There’s still a major structure of the Wave content I still haven’t fully grok’d regarding annotations and elements. Since this is mostly for visual support, and I was focused on a non-visual tool, it got back-burnered for another day.

Once I understood that I could not rely on having access to all Blips in the Wave at all times, I realized I was going to have to establish some persistence of data. App Engine’s Data Nucleus Java persistence is excellent for this type of requirement. With little effort, I was able to create a mechanism that could store and retrieve a list of Java objects without having to use JDBC or proprietary persistence APIs. The other service that App Engine offers that I needed was email support via JavaMail. In the future, I will also try their XMPP service for Google Talk subscriptions.

After 2.5 days of effort, the outcome was highly successful. The command-line Robot that I called Checkwave is now published and available for anyone to include in their Wave. It support subscribe, unsubscribe and list functions. When you update a Wave all subscribed participants receive and email with text content of the Blip that was added and it includes a hyperlink that brings you back into the Google Wave environment with that Wave on screen.

A more technical description of the Robot can be viewed at http://checkwave.appspot.com.

Having developed a secure instant messaging platform at Ikimbo back in 2001 that allowed for robots and in-context replies, I am a big fan of these features in Wave. IM is great, but a conversation among multiple participants can become unwieldy to follow. The ability to explicitly address a prior message in context is a huge advantage over traditional IM systems. Moreover, the ability to facilitate this communication asynchronously is another major plus. Getting people to use a new tool, however, is a very difficult task. For me Checkwave was a critical tool to assist me in bringing people back to the Wave.

All in all, working with Wave was a pleasant experience and I look forward to seeing where Google takes this platform.  Some additional notes that people may find useful regarding Google Wave robots:

1.  Multiple robots in the same Wave can have unintended consequences.  When Cartoony and Checkwave existed in the same Wave, Cartoony would turn my text to graphics before Checkwave had an opportunity to read it, hence,  it broke the command-line capabilities.

2.  As the owner of information now entrusted to me by those using Checkwave, I realize that I must protect this data, but it also made me aware that any Robot you add has access to everything that occurs on that Wave.  So, you need to be careful which Robots you add to your Waves as you are providing implicit trust of any data provided through that Wave.