Google’s Wave has also come with a host of new development APIs for creating bots and embeddable gadgets. I have not had the chance to mess around with gadgets yet. However, I have been working on a simple bot for Google Wave (see below), written in Java. This project was started to create group management for the Fortress Forever community on Google Wave. Currently the community is extremely small; only seven people. Some of those people may not even remain active on Wave; they just wanted to see it and mess around with it. Anyway, that has not stopped this small project. It started out with simple group management, but is progressing to something bigger, badder, and better.
This is the first in a small series of small reviews about Google’s bot API. As I discover new things about the API, I will review them here. This first article will focus on the basics of the API overall. Subsequent articles will delve into more specific things. This particular article will also be focusing on the Java API, as I have not experimented with the Python version of the client library yet.
The Basics: Pros
Overall, the API is very straightforward for a platform that is as complicated as Wave. All of the complications of the Wave protocol are hidden inside a nice client library (currently Python and Java versions exist). Bots written in Java are J2EE web applications that build on the foundational concepts of servlets. The Java bot API provides a servlet class named AbstractRobotServlet.
You must extend this class and implement its processEvents(RobotMessageBundle bundle) method. This is the entry point for the bot, and will be called every time an event is raised by the Wave platform. From the RobotMessageBundle, you can get the wavelet that raised the event, as well as check some event types. Once you have the wavelet, you can do more things such as create new wavelets, append blips, edit text, and more.
The Basics: Cons
The most annoying thing I’ve found so far is that certain bits of information you may want use in order to process an event tend to be spread across the RobotMessageBundle, the Wavelet, and the Blip objects. This leads to one passing around the three different objects to fully process different events. This problem mostly arises as a design issue in the software, though. With proper design practices, passing around all three objects as parameters to methods can be avoided. However, I don’t see it being completely impossible that a framework built on the Wave robot library will arise.
The other thing I have found to be of minor annoyance is having to increment “version numbers” in the capabilities.xml file when a new event is added to the bot. This forces Wave to update its list of known capabilities on the bot. It seems a bit obtuse, rather than just having a forced capabilites.xml update whenever a new version of the bot is deployed to Google’s App Engine, or allowing the user to manually trigger an update the next time the bot is hit from Wave. I suppose the forced update on every new deployment would eat up more of Google’s resources than necessary, but the manual trigger for an update wouldn’t be that bad.
Perhaps the versioning stuff could be abstracted by the Google Plugin for Eclipse with a checkbox on the deploy screen that gives the option to force the Wave to update the bot’s capabilities cache. It’s a small change (and definitely of low priority given everything else that needs to be finished first), but would make things even easier/straightforward.