Today Google released their open source Google Gears extension for Firefox and Internet Explorer. Also announced at the same time was upcoming support for the Safari and Opera browsers and inclusion of the technology into Adobe's Apollo framework. All these things should help make the concepts underpinning the software fairly ubiquitous. You may at this point be asking yourself what is Gears? In a sentence it is a set of Javascript API's and supporting backend functionality to enable offline use of Web applications. For more information on the subject I would recommend checking out David Berlind's recent podcast interview with Linus Upson of Google on the topic.
Google Gears is big news because a Web-based application's biggest stumbling block has always been the fact that if there is no Internet access your application stops working. If you are like me and write Web-based database applications then this is really interesting because it opens up opportunities for your users to access their data in a variety of ways that are currently impossible. For example WhichDoctor manages physician information ranging from their contact information through to their training history. From my perspective it would be nice for a user of this application to be able to pull down a sub-set of this data so they can take it away to a secluded beach to work on for the weekend. Gears helps in realising this functional requirement on the browser but for existing and complex applications like WhichDoctor there is still a great many problems to overcome before such a possibility becomes reality.
Off-line enabling a legacy Web application
Gears is great if you are starting out with a brand new application because you have the opportunity to design the architecture and interface from scratch to work seamlessly with this new on-line/off-line paradigm. However in an existing application where there is already a well-entrenched user-interface and code base that cannot be simply thrown away taking advantage of Gears is a more complicated process. For example it is unrealistic to suggest that each client keep even partial copy of the entire database schema if it is complicated and has a lot of business logic associated with it. In this case it is my opinion (at the moment) that the wisest course of action is to utilise the page-caching capability of Gears alongside a greatly simplified browser-based SQL database for basic searching. Such a strategy would provide a limited yet functional off-line experience whilst working within the constraints of the existing codebase and database schema.
In the above diagram above the user of the application would identify a subset of the total database population they would like to have 'synced' to their browser. The server would return this subset in XML or JSON format so that it could be parsed by the browser and inserted into the off-line database. The resultset would include basic search fields, for example if related to people it would break the names down to their first and last components so that relatively basic, browser-side searches could be performed (e.g. everyone with a last name of Harrison). Once inserted the routine would then loop through the dataset and request the associated HTML 'view' of each piece of data from the server for storing in the file cache. During the server-side page rendering process any application functionality not available in the offline, cached version would be excluded to ensure a smooth user experience (there is no point confusing the user with options that do not work). With the dataset and cached pages all stored locally on the browser the user would then be able to go on holiday and use the application in partnership with their data-subset quite happily.
Off-line write operations
The example given above does not include write functionality which would need to be implemented at a later date. Whilst possible with Gears version control in the event of an off-line data change would raise a couple of issues that would need dealing with. Firstly any offline data change would require some notification or re-rendering of the cached version of the page view so to notify the user the underlying data had been modified. Secondly when returning to an on-line state and the change committed to the primary database a consistency check would need to be made to ensure newer data did not already exist in the database, the last thing we want to do is overwrite new data with old.
Conclusion
Google Gears is a great development that holds significant potential for Web applications designed with it in mind. Off-line enabling existing Web applications, especially complicated ones is a challenging task that will only be achieved through a number of small but logical first steps. Still it is great to see off-line capability enter the vocabulary of the Web application. In the long-term off-line innovations such as Gears will have as significant an effect on the Web application market as AJAX has had in the last few years.