Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
Since Google's Developer Day, I have been promising to speak more regularly about Google products. This is a bit of a balancing act for me as I want to avoid the slippery slope of becoming a corporate sock puppet. I also don't want to neglect my real interest in connected systems, SOA, and asynchronous messaging. With the Internet turning into the largest connected system (see my The Cloud as the New Middleware Platforms track on at QCon), the gap between Web-based technologies and connected systems design has become significantly smaller, allowing me to combine interests and Google developer products more naturally. Of course, the fact that Google is rolling out new developer products and API's around the clock, does not hurt either. What's funny, though, is that my first official external Google appearance was staged in the land of the rising sun, far far away from Mountain View.
So it was just a matter of time until I took a closer look at Google Gears. While I have no aspiration (or hope) to become Mr. Gears, I find Gears to be quite fascinating. Like many new technologies, Gears was a bit
misunderstood at the beginning. Many people (myself included) equated Gears with offline
browsing. I think to some extend this image was reinforced through many of the early
demos, which focused on making all sorts of Web sites (Wikipedia, Google Maps, what
not) available offline. While this is very tempting (I could not resist but build
my own offline calendar app in Gears), looking only at offline is a very narrow view
on Gears.
Gears is primarily about enhancing browser capabilities across multiple browser platforms. While browsers are very powerful platforms, developers still have to deal with a number of deficiencies. It's in Google's best interest to enhance this platform because the vast majority of our applications are delivered through the browser. The initial set of API's includes the following features:
These functions are available to JavaScript running inside FireFox, IE, or Safari (soon). The function set is well suited to data synchronization for offline applications, but storing data and resources in a local database can make even connected applications much more responsive. Plus, the resource manager, local database, and worker pool are just the initial set of functions. The Google Gears Wiki shows a variety of proposed API's for subsequent versions of Google Gears.
This seems like a good time to point out that code.google.com is a little schizophrenic. It's an open source code repository as well as Google's developer support site. You could say it is MSDN and Sourceforge in one. Likewise, the content related to Gears is split into two distinct parts: the open source project repository and the Google Developer site. It kind of makes sense when you consider that Gears is an open source project (which happens to be hosted at code.google.com), but is still considered one of Google's supported developer products (so tutorials and documentation are available just like for other APIs).
Google Japan has been hosting a series of "developer round tables" to share information about Google API's and developer products with the local community. I like the format – it typically consists of a presentation followed by a panel discussion. I stated many times that I am a big fan of panels – they provide the kind of interactivity that you can't get from a blog. Roundtable #4 focused on Gears, and I had a chance to take on the presentation slot, which will be made available on video. The panel was held in Japanese, so that was off-limits for me because people wanted to hear more than "eki wa doko desuka", i.e. "where is the train station". The panel consisted of two Google developers and four invited guests, moderated by Naoki-san, a product manager and developer relations manager in Japan. Most of the panelists demo'd applications they built in Gears and described their experiences building these applications. I really enjoyed this focus on real developer experience -- this was definitely not a marketing event! Ichikawa-san, one of the Google developers on the panel, showed a demo application that can suggest keywords as the user types into an input field, similar to Google Suggest. The application is extremely responsive because the application uses a local SQL database with a 'LIKE' query clause.
When giving a presentation about Google Gears, what would be better than actually making a Gears application that renders the presentation? That's what the sample application, that comes with Google Gears, does. It reads a text file into the local SQLite database and renders the presentation from the database records. On slide 10 of my updated presentation you can cache all application resources (e.g., images, JavaScript files, CSS files, etc) in the resource manager and run the presentation offline (naturally, following this link requires Gears). I demonstrated that feature during the talk by pulling the network cable right after synchronizing. Thank god it worked. I hope it shows on the video! I uploaded the presentation application with all supporting files to the code.google.com subversion repository.
In a lucky stroke of genius, a Japanese publisher managed to publish a book on Gears the very day of the roundtable. Naturally, the book got a bunch of free PR during
the event. Ito-san from WebOS Goodies pointed out that more powerful API's in the browser will lead to less dependence
on server resources, reducing server cost. This may enable more people to implement
their dreams to create web applications.
The event also included a Q&A session, giving the audience a chance to pose questions directly to the developers or the invited panelists. Of course, it's also useful feedback for us to hear what concerns developers. Questions included Google's future plans (naturally, the answer is a little vague), especially the relationship to the offline support coming in FireFox 3.0. Google and Mozilla are actually working quite closely, so I don't see much of a conflict. Also, Gears is a cross-browser platform API, so it's inherently broader in scope than a FireFox only feature. Lastly the FireFox off-line capability does not include an actual database that can store and search structured data.
Naturally, attendees were curious about Gears support for mobile applications. It's easy to see that Gears' features are particularly interesting in a mobile environment where high latency and spotty connections can plague browser applications. With Android around the corner, I am sure we are bound to hear more about this topic.
Developers also pointed out that the Gears API's are relatively low level building blocks, making more guidance and advice from Google essential. A recent article on the Gears Architecture clearly points this direction. This is a topic close to my heart. I want to make sure that developing rich and responsive browser apps is not reserved for hard core hackers and JavaScript junkies. While the "competition" (a good friend of mine, actually) has been getting a lot of air time regarding Democratizing the Cloud, it's equally important for Google to bring Web development to the masses. A little voice in my head tells me that there may be some interesting design patterns for these types of applications waiting to be documented. AJAX Design Patterns is a good step into that direction, but Gears has fundamentally changed the landscape for AJAX development.
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.