With the consumer release of Google Wave scheduled for the 30th of September, InfoQ had a Q&A with Google Software Engineer Dhanji Prasanna about some of its less known internals, details about how it’s being developed by the Google engineers and the best practices involved.
InfoQ: With Operational Transformation (OT) being a corner stone of Google Wave, would you like to tell us a little bit about the technologies that implement it?
Dhanji: OT as a concept has been around for some time, mostly in academic form. We have a complete clean-room implementation of OT, customized to the particular needs of Google Wave. It has enabled our editor to be a truly real-time, character-for-character, concurrent editing system. By decomposing edits to a document into streams of mutation operations, we are able to maintain the semantic consistency and integrity of a single line or paragraph while it is being edited simultaneously by several participants. This is at the heart of the real-time collaboration story.
OT in Wave draws in large part from the aforementioned academic papers, and the Jupiter system. One advantage to us using the Google Web Toolkit is that the same OT Java code that runs on the server also runs on the client. This is a particularly important saving for us. You can read more about this technology at http://waveprotocol.org and play with the actual source code at http://code.google.com/p/wave-protocol
InfoQ: It seems that you have used GWT and Gears for building the web client? Would you like to tell us why you choose this set of technologies and what were the challenges you had to overcome. Also how are you planning to cope with older browsers?
Dhanji: The Google Web Toolkit has been a great success story for Google Wave. We are able to leverage Java testing, debugging and code development tools, which are very useful and familiar, and delivering this to a browser in a compact, performant and scalable form has been a real eye-opener for us. GWT is able to pluralise a common codebase among a variety of browser and OS permutations, including with minimal effort, mobile browsers. It also optimizes away a lot of code, so we are able to use idiomatic Java but still have it run fast and delivered compactly to the client. We currently use Gears only for one feature, and that is to enable drag-and-drop into the browser (from the desktop). This is a feature we are trying to get added to HTML5 so even browsers that are not Gears-enabled will be able to take advantage of drag-and-drop.
We currently support modern browsers (browsers with similar capabilities as Chrome) and will, in the future support any HTML5 compliant browser fully.
InfoQ: With the growing variety of browser+OS combinations, how do you manage testing, integration and frequent releases for the web client?
Dhanji: We are fortunate that we can draw on a lot of experience in this area that other projects and engineers at Google have. In addition to having a terrific team that focus on testing technology, we use a wonderful open source web-testing library called Webdriver that allows us to mimic user interaction in quite sophisticated ways with the Wave client. Webdriver makes it easy to parallelize such tests among various browsers with simple pluggable options. It has also evolved quite a lot to support our unique Ajax-heavy testing requirements. Apart from this we have an aggressive release schedule that lets us propagate bug fixes and feature updates quickly. But perhaps the most significant safeguard is that we use Wave internally ourselves for nearly everything; eating our own dogfood, so to speak. This really helps us keep on top of high priority bugs and much-needed features as we feel their pain first.
InfoQ: Would you like to give us an overview of the kind of software that someone would find on the typical workstation of A Google Wave Engineer?
Dhanji: Each engineer has their own specific preferences for tools, but apart from the regular version-control, management and build tools that are common between all Google engineers, you will find anything from Eclipse, IntelliJ Idea to vim and emacs as code editors of choice. Command-line unix tools and custom shell and python scripts to manage various repetitive actions are also quite popular: grep being the favorite, perhaps. =)
InfoQ: Would you like to give us a short technical outline of what happens to a message (blip) from the moment a user types it in the web client, until becomes available to every one else that is participating in that wave – humans or robots? What systems need to be bootstrapped, what technologies are utilized and what is the flow of information?
Dhanji: Sure, a message written in the client is transformed into a series of operations that are sent to the server in real time. After authenticating and finding the appropriate user session, the ops are routed to the hosted conversation. Here these ops are transformed and applied against other incoming op streams from other users. The hosted conversation then broadcasts the valid set of changes back to other users, and to any listening robots. This includes special robots like the ones that handle spell checking, and one that handles livesearch (seen in the centre search-panel), as well as explicit robotic participants that people have developed. Robotic participants write their changes in response to a user's and these are similarly converted into ops, applied and re-broadcast.
The Web client interprets these as appropriate; in the case of spelly, it highlights the misspelled word for correction, for example.
Like other Google applications, the various systems run on a cluster and scale horizontally (Web search for a planet: the google cluster architecture - Micro, IEEE).
InfoQ: How about the licensing of the software that was built for Google Wave? What parts are open source now, what parts are you going to open source in the future and what do you think might be the overall licensing strategy that Google will follow?
Dhanji: We currently provide (as open source) most of the core data model for document transformation and manipulation. This is the same code that runs on our internal systems. We also provide a reference implementation of a server and client that use similar approaches to our internal systems. We intend to open source a lot more of our code base, however it is a big job as we must disentangle the code from proprietary infrastructure, provide appropriate build tools, and ensure that it is properly documented and supported before releasing.
We use the Apache Software License (ASL 2.0). I cannot comment on licensing for products other than Google Wave, as I am not familiar with them.
InfoQ: How appropriate do you think current “best practices”, frameworks and technologies are for building a platform like Google Wave? Do you think that the choices you make in high-end projects like that are a glimpse of what will become mainstream in the future?
Dhanji: There have been many challenges we've faced in building Google Wave. We've had to learn a lot about the nature of scaling a real-time, character-by-character application that supports both human and robotic participants natively. There is also a large challenge to maintaining a code base with 50+ engineers, to onboarding them and keeping the health of the build constant at the same time.
The core libraries and tools used at Google have proven invaluable, in this effort; some of these are available as open source and we highly encourage their use: Google Web Toolkit (which reduces our client footprint by an order of magnitude), Google Guice (particularly the Servlet extension), Guava Libraries, Webdriver and several others. Many of these are bleeding edge technologies that are continuing to evolve at a fast pace. We've been particularly lucky to have the authors of these toolkits work closely with us and accommodate often oblique requirements. Anyone attempting a large project like Wave will find these open source libraries extremely useful.
InfoQ has also published a news story about the Google Wave Architecture and will continue to follow Google Wave developments.