Gear up

Yesterday, while looking over to the Google Gears (GG) stuff, I talked with Celso about this and that I was pretty excited with the possibilities it provides. He was not impressed and later he told us why.

I'm going to pick on his arguments for a while and then, in a followin post, tell you why I like Google Gears and where I think I can use it today. I don't think it is the 8th wonder of the world, but I think it is a very good step in a good direction. Also note that I'm a desktop app fan, and all this hippie-ajax-the-web-as-your-desktop-thing is not the way I see things evolving. I think I wrote something about this in the past but basically, a Web2.0 world feels like the glorious years of the mainframe and the time sharing days. But as always, the truth is probably in the middle ground between a Web2.0 app and a desktop app, so any move to push web apps more to the desktop is a good move.

Celso starts of with the fact that upcoming browsers like FF3 are already talking about offline storage and support for offline apps. I haven't looked at the specs to compare with GG, but even if they are as rich as GG is now (the SQL database and the worker pool stuff is really very useful), there is no reason not to use the GG API as a front-end to whatever the browser supports. This would mean that I can start now, with some hope of having even more support and features in the future. Having GG now also force browser vendors to have a goal: if FF3 appears without features as GG has, less richer, it might seem as a failure (this assumes of course that the GG feature set right now is a good one, still to be proven in the field).

Starting now is important. Sync between data-stores can become pretty hard pretty fast, so we need to experiment, and the sooner the better.

The Zimbra remark is also interesting. Zimbra showed of their Desktop client at eTech. Notice the name: Zimbra Dekstop. Why did they called that? Because you need to download and install a desktop client. It is in fact a small server running on your local PC that you browser will use while in offline mode. It is a perfectly acceptable solution, and extremely powerful, just not a direct comparison with GG. Or then again, it might be, if you think that GG just moved the Zimbra Desktop server into the browser.

The advantage in my mind of GG over what Zimbra has done, is that we now have a solution that everybody can use, and like Flash, it's easier to find it installed on users PCs than something that only one app will use, like the Zimbra server.

But this brings us the open questions Celso has.

The first one is pretty much answered above. When FF3 appears with offline storage, I suppose one of two things will happen. If the FF3 system is as powerful as GG, then the most likely is that GG will just defer to it, but keep the API compatible. If FF3 is not as powerful as GG, then I believe that it might not have as much success as they hope. Its very difficult to go back to a inferior product.

There are two things that make me guess that "it will work out fine". First Google works very closely with the FF team, so it might just be possible that the FF team just uses the GG stuff, dropping the google prefix. Or the FF3 distribution just includes the GG plugin. Both are perfectly possible. Only time will tell.

Right now, though, FF3 offline stuff (I could only find a wiki entry of the BarCamp in New Zeland, a FF3 Gecko Feature list, and a blog post by John Resig) looks pretty simple. I think you can compare it to the basic ResourceStore class. The stuff in GG, specially the Database API is much much more powerful. But both products are Alpha or Beta, so too soon to tell.

The second question is why will someone download and install this. I suppose the same could have been said about Flash some years back, and the answer could be similar: because hyped-up sites might start to use it and the cool kids will have it. Basic primitive human behaviour: "That looks cool, why don't I have that?". I do think Google has a big edge over Adobe and Flash in this case though, that might make the adoption of this pretty fast. There at least two things in Google favor.

First, Google as a lot of ways to push this onto users systems: you might just bundle it with any of Google software like the Google toolbar or any other of the software they distribute. Its easy for Google to just slip this into their new Google Updater as an option.

The other one is that Google Apps have a lot of visibility: if you add support for GMail, Maps, Documents, or Calendar in a way that you can have some of your data offline, users will want to install it to have that support, and once installed, everybody can use.

The third question its pretty much answered above, but the part about other browsers adopt the same API, well... I would love to have that, and it might just happen if the HTML5 proposal sees the light of day. At least they do have a sort of key/value offline storage system and a client-side database storage based on SQL (for kicks, I quickly skimmed over it, and a lot of the concepts are similar to GG and would map pretty well).

So overall, I think that GG is not something terrible new, of course, but it does a lot of things better than before, and it has a chance of being much more widely deployed (IMHO) than the previous alternatives. Also, upcoming support inside the browser for this kind of stuff will only help GG.