JP Morgenthal

Google Wave on Ulitzer

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.