Google Gears is an open source browser extension that lets developers create web applications that can run offline. Gears provides three key features:
- A local server, to cache and serve application resources (HTML, JavaScript, images, etc.) without needing to contact a server
- A database, to store and access data from within the browser
- A worker thread pool, to make web applications more responsive by performing expensive operations in the background
Gears is licensed under the New BSD license allowing the embedding of the Gears runtime API into third party software with minimal restrictions. At present installation is in the form of a browser extension (around 700k in size) that supports IE and Firefox on Windows, and Firefox on Linux and OS X. Support for Opera and Safari is in development.
Digging deeper into the three components provided:
- LocalServer
The LocalServer is a specialized URL cache intercepting requests and serving them locally when needed. There are two types of "resource stores" of urls. The most basic of the two is the ResourceStore which allows applications to store ad-hoc user data files associated with a url like a PDF or image. Such cached urls must be explicitly updated by the application. The second type of resource store is called the Managed ResourceStore. This consists of a set of urls defined by a manifest. This set may be automatically updated when the manifest's version number changes. Gears will periodically check if a managed resource store has been updated.
Database
In addition to a url cache Gears also includes a SQLite database instance. Data stored in the database is partitioned by domain and can not be accessed from a different domain other than the one storing the information originally. The syntax to access the database from Javascript looks very similar to JDBC:
resultSet = db.execute (
'INSERT INTO MYTABLE VALUES (?, ?, ?) WHERE id=?',
[1, 2, 'three four', 5]
);
while (rs.isValidRow()) {
console.log(rs.fieldName(0) + " == " + rs.field(0));
rs.next();
}
rs.close();
WorkerPool
The final element included in Google Gears is the WorkerPool API. The documentation defines the reason for its inclusion as:
In web browsers a single time-intensive operation, such as I/O or heavy computation, can make the UI unresponsive. The WorkerPool module runs operations in the background, without blocking the UI. Scripts executing in the WorkerPool will not trigger the browser's "unresponsive script" dialog.
The WorkerPool behaves like a collection of processes instead of individual threads. Workers do not have access to the DOM only Javascript functions. An onmessage callback is used to perform activities when the worker receives a response.
In terms of initial adoption in Google own web applications, Gears has already been integrated into Google Reader:
The GWT team has also put together the Google API Library for Google Web Toolkit . The Gears API integration takes advantage of GWT's JavaScript Native Interface (JSNI).
Google would like for Gears to become a standard for offline web application development as is indicated in an interview by ZDNet's David Berlind with Google's Linus Upson:
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.
As a first step in those efforts Adobe has announced support of Google Gears. Berlind's article provides more details from Adobe's Michele Turner:
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 ... 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.
As a demonstration of this integration Adobe's Christophe Coenraets built a Flex application integration with Gears that was demo'd by Kevin Lynch during Google Developer Days. Coenraets also built a SQLAdmin app to help manipulate his Gears database while building the demo.
The announcement of Google Gears also raised speculation as to the future of the Dojo Offline Toolkit. Ajaxian caught up with the project's lead developer Brad Neuberg on the subject. He indicated Dojo was in the loop on the announcement and that he's already ported Dojo Offline to use Google Gears as the base platform. Listen to his interview for more details.
RedMonk also has detailed Gears coverage. Stephen O'Grady speculates on the impact of Gears on some existing alternatives:
From an application provider perspective, I tend to agree with Berlind, who said:
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. If you’re Zimbra, and your resources are limited, it would make sense to at least ask the question as to whether or continued investment in a redundant offline infrastructure was justified. It could be, for technical reasons, but it might not be as well.
If you’re a Joyent, the question is more complicated. They’re targeting a far more specific niche than Google Gears, in Rails apps, so the question will come down to whether or not Slingshot can offer enough differentiating features to Rails devs to justify their usage of it. Compromising their argument is the fact that Slingshot is not, as yet, available on as many platforms as Gears. Still, they appear content to play David.
Interestingly, Adobe seems to be partnering quite closely; willingly aligning their SQLite efforts with Google’s. That bodes well for Google’s ultimate aims.
With the momentum of offline web application development growing in the form of Gears and Apollo among others, web application developers will have to start considering what "offline" means for their individual application. Basement.org comments on this task of "unlearning":
The desktop paradigm: files stored in folders that I can "take out", work on and put away, is a very powerful one ... But there's also a cost in not really knowing where this asset lives. How do I give it to someone else? How do I delete it? How do I move it? Of course, those of us well-versed in 2.0isms write these questions off as a failure to understand this "new way of doing things." Not so fast. People understand the representation of a file. For just about everyone, a file - whether a spreadsheet or document or image has what I like to call "cognitive integrity." ... It'll be interesting to see how designers approach the challenge of helping users grasp and take advantage of the shifts that are occurring today. Before we embark on that path though, we should make certain the value is really there and that it outweighs the unlearning process that will inevitably have to occur.