Google Gears: too much interface?

So I had a quick look at Google Gears this morning. Unlike some, I do most definitely see value in supporting disconnected scenarios, not because I don’t see pervasive wired and wireless networks being the rule in the not-too-distant future – I do – but because I understand that networks are unreliable. That said, I do have some concerns about how Gears was put together.

My primary concern is that I’ve always felt that supporting offline use in existing browsers required more innovation of implementation rather than interface, whereas Gears is all about interface. What I mean by that is that I believe that a better, more easily deployable and usable solution would be for Mozilla itself to tweak the implementations of its HTTP stack, cache, and XMLHttpRequest object. Instead, Gears gives us new interfaces like LocalServer, which developers are supposed to use to check for valid cached representations before hitting up XHR: something XHR could very well do itself, largely transparently (I expect – haven’t considered all the backwards-compatibility issues).

Now, Gears could very well be something that was deployed for its ability to enable features today, because Google didn’t want to have to wait for HTML 5 (and its equivalent of client-side storage) to be deployed. And from that perspective it’s great (though requiring a plugin is a bit of a pain). I just hope that the Gears folks are talking with Hixie and Mozilla about where to draw the line here.

0 thoughts on “Google Gears: too much interface?

  1. Ian Bicking

    As far as I know, XHR goes through the same fetching stack as any other web request, meaning that the cache is checked, cookies sent, etc. But there are still times when on the application side you’d like to know if the cache would be hit. Then, for instance, you can give the user some indication of whether some action is possible to perform, instead of performing the action and getting a failure.

    Actually augmenting XHR is also probably hard for them to deploy now. At least from the Javascript side I’ve had a hard time manipulating that object reliably (not that I’ve tried that hard, but I imagine they might try that hard). It might be nice to simply, for instance, add a .can_open() method (instead of just .open()), that guesses as to whether the request would work (using some knowledge of the offline status and the local cache). Anyway, it would be rude of Google to extend XHR; extensions like that should be discussed first. And discussions are best done with concrete examples, and Google Gears is the concrete example; so maybe all is as it should be?

Leave a Reply

Your email address will not be published. Required fields are marked *