Google Gears is a browser plug-in to support running web applications offline. It has several components:

A local server – not a complete web server, but a cache for web pages. One of its benefits is to solve versioning issues. For example, what if you had an application that retreived one page from the cache, complete with Javascript, and another from the Web, including some updated Javascript? The app would likely break. The Gears local server lets you define a set of pages as an application, so you can ensure that either all or none of the pages are delivered from the cache.

A local database. SQLite of course. I can think of many uses for this – whether or not your application needs to work offline. Searching and displaying data from a local database will be quicker than retrieving it remotely. In the current beta, there is no limit to the size of the database you can download or create on the user’s machine.

A WorkerPool for running Javascript in a background thread. Again, there are many possible applications, but a key reason for its inclusion is so you can do long-running synchronization tasks in the background.

A Javscript library to enable access to all these goodies.

Synchronization

Synchronization is integral to the Gears concept. The idea is that your web application works the same online and offline; and then when you reconnect, any changes you made offline are transparently synched back to the server. Google’s demo app for Gears is Reader, a blog reader app, but you can see how this would work nicely with Documents and Spreadsheets, removing one of the disincentives for its use. I’m reminded of comments from James Governor and others about the Synchronized Web – cloud storage, but with full offline capability.

Gears vs Apollo

How does Gears impact Adobe, which is promoting offline web applications in the guise of Apollo, desktop applications running on Flash? You can argue this either way. On the one hand, you could say that Gears removes the need for Apollo. Now any web application can work offline. On the other hand, you could say that Gears is not targetting the same space. Apollo is for desktop apps; Gears is for web applications that happen to work offline.

My take is that Google is making its pitch for ubiquitous web apps which break the offline barrier. The attraction of Gears is that it is seamless, at least for the user. Look at the reader example: it’s the same app, but now it works offline. As I see it, Google is saying that you don’t need Apollo (or WPF, or Java) for compelling apps that work connected and disconnected. That said, it’s not against Flash; there are even handy Google Javascript APIs for simplifying SWF hosting.

Another twist is that Adobe says it is supporting the Gears API in Apollo. That presumably means Apollo now has a fast embedded SQL database engine, which must be a good thing.