Google Gears Extends Browser Functionality
Google Gears is a browser plugin that extends the functionality of your web browser, allowing for developers to create better performing web applications. Gears is an open source plugin that needs to be installed by the client if they choose to use it. Currently it is available for browsers on Windows, Linux and Mac OS X. While they claim that for the Mac it is only available for Safari and Firefox browsers, I would bet that Chrome is either already supported or will be soon.
Gears offers three modules, each of which adds a type of functionality to the browser that Gears in installed in that developers can take advantage of. The first, called LocalServer, provides a way to cache a web application on the client's machine for offline browsing. Database, the second module in Gears, provides a way for developers to store information on the clients machine in a fully searchable, relational database. The third module, called WorkerPool, is intended to help applications perform better by running intensive operations in the background. Let's take a brief look at each of these modules.
LocalServer Module
The LocalServer module allows a web application to cache and serve web pages and other resources (JavaScript, CSS, Images, etc) from the client machine, rather than having to request them from a web server. Such a functionality can improve the user experience of a web application by eliminating the need to contact a web server over the Internet, and also allows for offline browsing of pages that have been stored with LocalServer.
Developers that are creating web applications can interact with the LocalServer cache via the ResourceStore and ManagedResourceStore methods available in the Gears API. In both cases, developers can set the resources that LocalServer needs to store.
With ResourceStore each URL of the resource needs to be passed, which allows for ad-hoc storing of individual resources. This is ideal for single resources such as PDF files or images. However, developers need to be sure to manually update the resource when needed using the capture() method. Otherwise, the resource will not be updated and the information stored in LocalServer will be out of sync with the web application.
Working with ManagedResourceStore allows developers to define a group of resources which are automatically updated. This gives developers the control to be able to locally store a set of resources that are required by the web application. When using this method of caching resources, updating is done automatically and developers do not need to call checkForUpdate() periodically, as they would with the capture() method in a ResourceStore situation.
Of course, user permission is required for any web application to begin storing data locally on a client machine. Make sure that your customers are open agreeing to such a thing, or all your work is for nothing.
Database Module
The Database module provides a client-side relational database using SQLite. This gives developers a way to persistently store data on the client's machine for use by the application.
As with any application that is connected to a database that utilizes SQL, developers need to take care to prevent SQL injection attacks and other security-related issues that databases bring into the mix. Also, the same rules apply with regard to transactions and ensuring that if there are multiple processes trying to write to the database, one can fail. However, since most developers are used to working with databases anyway, this is not that big of a barrier to get over.
In the same way that the LocalServer provides a way for HTTP resources to be served from the clients machine rather than from the web server, the Database module provides for a way to cache data locally as well. The idea that someone could use a web application offline to search through a directory of companies, or to refer to archives, is now a reality. Not only that, but database related actions and processing can be offloaded to the client's machine as well, so that even a web application that requires in Internet connection to access can perform faster and give the user a better experience.
As with the LocalServer module, clients will need to give permission for the Database module to be used. But again, as with most things that run on the client side, you only need their permission once. It also forces developers to explain to the client (or visitor) what is happening and why it is a benefit to them.
WorkerPool Module
The WorkerPool module provides a way for web applications to run JavaScript code in the background. In the same way that Ajax uses asynchronous JavaScript requests to interact with a server, WorkerPool uses asynchronous JavaScript to act as a background processor. In other words, you can have JavaScript performing processes without stalling the user interface, or waiting for them to complete.
The obvious benefit here is that JavaScript processes can do things without the user having to wait for them. Often times when a very intensive JavaScript operation is running it will cause the browser to be unresponsive until it has completed. This is obviously a usability issue that affects the clients user experience. By shuttling these processes to the WorkerPool, they can be freed to process on their own time while the user interface is free to do it's own thing.
One really interesting thing about the WorkerPool module is the idea of "messages", which processes can use to communicate with each other. Once a worker, or process, is created it is immediate able to send and receive messages from other processes, which allows them to interact. For example, one process may need to notify another process once it has completed. Or the fact that a process is running may require that it send a message to stop another process. Either way, the way that WorkerPool handles process communication is impressive, and provides developers with an impressive set of tools to work with.
While I haven't exactly figured out the widespread use case for Google Gears, it does seem to be an obvious progression with regard to rich web applications that offer the kind of performance that desktop applications offer. By moving certain parts of the applications functionality to the client machine, resources are used more wisely and a more "desktop like" experience can be created.
Taking a look at Google Docs and some of the other applications that can use Google Gears, it definitely seems like there was an issue with browsers that was limiting the application development. The simple answer is to "make the browser better", which Google Gears seems to accomplish. I'm looking forward to seeing what other kinds of modules get introduced into this toolset in the coming years.
This post is filed under Developers' Corner and has the following keyword tags: google, gears, browser plugin, javascript.
