Google Gears

Google is at it again, this time maintaining its position at or ahead of the curve with Google Gears.

What is it? It's the latest in a great trend toward allowing for creating hybrid web apps that can run on- or off-line. Google Gears is by no means first to the party, however. Joyent was out the gates early with Slingshot, which we had the pleasure of getting a look at up at RailsConf. Adobe is also trying to get in the game (from an admittedly different angle) with its work on Apollo. Add in to this mix the browser-as-dev-platform path that Firefox 3 might be taking, and we can see that the world is moving very rapidly toward a synchronizable, online/offline world.

So why do we care about Google Gears? I'm sorry, that was a stupid question. We care because it's Google, and they have the intellectual resources to really solidly address this path, coupled with their penetration into just about every technological market. Also, they're following the grand tradition of their code projects, and opening a lot of code base for use by developers. The APIs are documented and available, and they're encouraging devs to play with the beta.

Gears provides the following basics, as quoted from their site:

	LocalServer Cache and serve application resources (HTML, JavaScript, images, etc.) locally
	Database Store data locally in a fully-searchable relational database
	WorkerPool Make your web applications more responsive by performing resource-intensive operations asynchronously

This should be enough for any web app developer to get off the ground and running, building relatively responsive RIAs... on the desktop.

Ok, enough drooling over docs. I'm going to go dig into it.

I'll probably post back later with impressions, but feel free to throw your comment in, too. I'd love to see how this is responding with different frameworks and on different platforms.