'Google Gears' vies to be de facto tech for offline Web apps
For at least a couple of years now, critics of Web applications like those served up by Web giants Google, Yahoo, and Salesforce.com have argued that those apps can never replace their desktop counterparts because of the so-called "off-line problem." The offline problem is where a loss in network connectivity causes users to also lose access to their application logic and data. Today, with applications like Google Docs and Google Spreadsheets, this is indeed the case. If you're composing a document and experience a sudden loss in connectivity, not only will you lose access to Google's word processing logic, you won't be able to save your document or open up other ones. Depending on how your browser responds to a loss of connectivity, you may even lose any work done since the last "save" took place. This of course is not a problem with locally run applications such as Microsoft Office.
Google CEO Eric Schmidt may have recently downplayed Google's role as a competitor to Microsoft when asked as much by John Battelle. But with today's launch of Google Gears -- an open source technology designed to make the offline problem a problem of the past -- Google is clearly taking a giant step towards leveling the playing field between locally-run (desktop) and Web-based applications. Provided Google's proverbial "Office 2.0" applications are eventually enabled for the capability (they're not right now), the complexion of the Office marketplace (and the application marketplace in general) is poised for a sea change. Given Google's approach to application delivery and business models, companies such as Microsoft may have their hands forced in terms of reconsidering everything from the architecture behind their existing solutions portfolios to the licensing costs for those solutions.
According to Upson, not only is Google announcing the technology today, it's open sourcing it under the new BSD open source license in an effort to establish it as the standard for offering offline functionality to Web applications.
The technology consists of three primary components. First, a local "server" which is not really a local Web server but rather a means for capturing all of the Javascript and HTML-based logic that drives the functionality of an application. Second, a local database using the open source-based SQLite for persistence of any data associated with the offline functionality. For word processing, one record could theoretically hold the entire contents of a document. For something like Google Reader (an RSS reader app from Google and, in a proof of concept, the first to take on the offline capability using Google Gears), one record might hold an RSS item. To the SQLite project, Google also contributed the necessary Javascript APIs for accessing SQLite from Javascript.
Thirdly, Google took a look at the single-threaded mentality of most Web browsers and realized that any hangup in a Javascript-based application could easily hang the entire browser (something that has happened to me several times!). So, Google solved that problem by making it possible for Javascript threads to run as background tasks.
According to Upson, where persistence of code or data is an issue, the technology is designed to create private sandboxes on a per Web app basis. So, going back to the so-called "server" from where the pages are retrieved (not "served") and SQLite, there will be partitioned instances of each for every Web application one might be running offline. Even so, Upson said the architecture is so lightweight that users shouldn't expect a heavy tax on local system resources in order to get the functionality.
Going out the door, Google is supporting the major browsers on all the major platforms including Internet Explorer, Firefox, and Safari and has pledged Opera support in the near term. Google isn't alone in launching Google Gears. It's partnering with the Mozilla Foundation and Opera (for obvious reasons) and the with Adobe. In the interview, Upson wouldn't comment on what Adobe's interests are. But I managed to track down Adobe's vice president of product management Michele Turner who told me:
Google got a hold of us and said they were coming out with an offline capability for browser-based applications and they thought it had implications for our Apollo [runtime]. So, we sat down with them and found out that if you looked across the three main components of Google Gears, we were developing identical technology to facilitate the offline component of the Apollo runtime (a component that allows Internet-enabled applications that run on the Apollo runtime to continue running without connectivity). For example, they're using SQLite and we were already incorporating SQLite into Apollo. So, now we're aligning our efforts with Google on things like the synchronous and asynchronous calls that must be made to the SQLite database in order to enable the offline capability.
Turner went on to say that Adobe intends to make Google Gear functionality more accessible to developers working with Flex and Flash action script. But she wasn't sure when that functionality would become available.
Google's Upson was not shy about his company's motives for open sourcing the technology. The idea, according to him, is to make it a standard in the marketplace now, without the need for standards bodies. With so few Web app providers offering such offline capability and with Google's war-chest behind the effort, the tech stands a pretty good chance at becoming the overnight defacto standard for running Web apps offline. At the same time, where companies have committed to an offline architecture as Zimbra has with its Zimbra Desktop (whose offline capability is powered by Java), those companies may be forced to completely reconsider that architecture if Google Gears gets market traction.
Upson and I covered a lot of ground in the interview. He described how synchronization should work when using Google Gears and talked a bit about what if anything needs to be done on the server side as well as where there's room for other innovation (for example, in the multimedia area). He also talked about how end-users would be able to manage the sandboxed partitions of code and data (for example, wiping them out the way you might individually wipe out cookies).