Making out with Google Gears
Couple of days ago, Google took the wraps off Google Gears – a framework that brings persistence of data and state into the browser.
Gears consists of three modules:
This is not a revolutionary approach. Companies like Zimbra have been doing this for a while now, but the difference is that Zimbra embeds the entire application within the server, while in the case of Gears the LocalServer is only a framework that allows you to build applications on top of it.
- Database: This a simple SQLite 3 RDBMS that will store anything you want it to store.It provides a layer to access almost all of the SQLite’s features. It also includes support for full text searching with the Fts2 extension. And in true blue web programming style, it also leaves the door open for SQL injection attacks.
- WorkerPool: These are the poor Orcs of Gears. All functionality triggered by the UI is passed on to the WorkerPool to execute in leisure. According to the documentation, “Scripts executing in the WorkerPool will not trigger the browser’s “unresponsive script” dialog.” None of the workers share any execution state and can at best be thought of as dumb crunchers, they just keep crunching away at whatever is thrown to them. As a result, there is no hierarchy in the system, because every worker is born equal (wow, the Googlers are commies!) it is up to the developer to do his design in such a way that if need be, he should place a traffic cop worker whose lone job is to track inter-worker messages.
Anyway, the geekery apart, these are some of my initial impressions of Gears:
The installation is simple. Go to the website and download the installer. The product is available for the Windows, Mac and Linux platforms.
On Windows, the installer downloads the required files and lodges itself as an extension in Firefox and as a Browser Help Object (gears.dll) in Internet Explorer.
Following a restart, this is what you get in the browser options:
Add-ons/Extensions tab in Firefox
Websites that are Gears-enabled will check if you have the framework installed and ask you for your permission to use Gears and its features.
The only major Gears-enabled product that is available now is Google Reader and what it allows you now is to download and store data and objects (images, files etc) locally, till you can sync it with the server again.
Once I had selected the offline mode, it downloaded 2000 items (which is a soft limit than actually downloading 2000 items that you may not have to download in the first place).
It took six minutes to download the items, which was not bad considering that I am on a lousy GPRS/EDGE connection that is barely usable these days. Your mileage may vary depending on the feeds you have subscribed to, whether they are full text or excerpts or if they have too many images in them and so on. And the data download happens only till the progress meter hits 50%, after which the syncing starts and no more data is downloaded. As a result you see 0% to 50% progress taking almost 90% of the time, while the 50% to 100% progress happens in a flash.
As expected, in the offline mode, new items load considerably faster since they are coming from a local database. The subsequent syncs also proceed much faster than the first one, which is only natural most times as it would contain much lesser data compared to the initial full sync. Interestingly, following the installation, all the reader URLs now have the ‘offsync=true’ flag attached to them. But I have to say that the framework is still very clunky and buggy. I often ended up with 0 unread items in offline mode and 100+ unread items in online mode with the same item set, as Items marked as read in offline was turning up as unread in online. Buggy!
So, what do I think about it? It is a promising concept, but it also requires a considerable bit of re-engineering of applications that can often be built far too easily for the web. Designing syncing and conflict resolution logic is not everyone’s morning cuppa and uptake would at least initially be slow for this one. As a technology, it is a bold gambit by Google. It is aiming to set the standards and in getting the first blow in and it is also trying to get developer muscle behind it (once the tide turns towards in terms of usage, the community and other companies will do the hard work for Google. It won’t have to keep racking its brains to release products all by itself).
From a user’s perspective, this is quite a nifty addition. It would be very familiar for people who already use syncing in their daily life using existing software like Mail For Exchange. But at this point in time, it is a developer-oriented release, is clunky and anything but seamless to use. Then there is the major problem of being able to maintain state between two different computers. The Google engineers suggest a workaround for this by asking developers to “store offline preferences locally,” which is not really a workaround anyway. So there is plenty of work to follow in this space too.