by Malcolm Rowe

Picasa Web Albums, meet Gears

Gears are cool.
Gears, by tim_d (used under CC BY-NC-SA 2.0)

Google just released a new way to use Picasa Web Albums — through a nice AJAX interface for Windows Mobile 6 touchscreen devices. This is interesting to me for two reasons. Firstly, because it’s the first project we’ve launched that I can say I had a meaningful role in developing (woohoo me!), but also (and perhaps less egotistically) because the interface also supports offline use via Google Gears for mobile — you choose which albums to save to to the phone, and can then use the application entirely offline.

And to use it when you’re offline, you don’t need to do anything special, just open Pocket IE, navigate to picasaweb.google.com, and you’ll see all your locally-saved albums. The Gears LocalServer intercepts requests for network resources and delivers them from the local resource store; we also make use of a Gears Database to locally persist your sync settings. You can even let it create a Picasa icon in your Programs folder, if you like.

Developing for mobile devices has some interesting constraints; for one, it’s a lot more important to think about unreliable networks and bandwidth and storage use. For example, if this were a desktop application, it might make for a better user experience to use a transparent background-sync model, like Google Docs offline, where the photos are synced offline automatically, rather than using an explicit “store this album offline” action. But on a mobile device, downloading photos automatically “in the background” doesn’t do much for your connection, and limited device storage space means that we don’t want to fill up your phone’s storage (especially as Gears currently only makes use of the phone’s primary storage device, typically Flash memory).

Along the way, we found that there was some functionality that we had to do without (like getting the number of rows affected by a database operation — though I fixed that in what will become Gears 0.4), and that some things needed careful handling, or didn’t quite work the way we expected.

Still, it’s early days for Gears, and it’ll only improve. If you’re interested, there’s much more about developing Picasa Web / Gears in Dion’s Google developer podcast.

Gears and HTML5

It will be interesting to see where Gears goes; on one hand it’s a great way to get new functionality into today’s browsers quickly — I don’t see IE6 supporting HTML5 any time soon, for example. On the other, I’d really like the functionality to be integrated into HTML itself and available by default; to that effect, I see Gears as operating to some extent as a rapid prototype for some of HTML5’s specification work. Longer-term, I’d like to think we’ll see the two converging: the HTML5 specification changing as a result of what application developers learn from working with technologies like Gears, and the Gears API changing to match similar functionality in HTML5.

Or, as Brad Neuberg put it:

Why can’t we rev the base infrastructure of the web much quicker, plus create more robust, open extension points along the entire web stack, ala Greasemonkey? Is Gears the answer to this? I’m not sure, but its the best answer we have today. Gears is a great way to get the conversation started, plus get HTML 5 out to today’s browsers.
Brad Neuberg, What Is the Open Web and Why Is It Important?

Though I think it’s important not to classify Gears just as a partial implementation of HTML5 — I don’t think it’s intended to be, even though there is a lot of overlap.

For example, while both support a client-side relational store, HTML5 provides an asynchronous database API, while the Gears Database API is synchronous (though there is also a proposal to also support the HTML5 API). Gears also guarantees support for SQLite full-text search, something that it doesn’t appear that HTML5 does.

HTML5 also doesn’t support desktop interaction, and the offline support is different enough that it would be wrong to suggest that Gears is an example implementation, even if they are both trying to solve the same problem. Finally, Gears provides a way to run threaded JavaScript, using sandboxed workers that communicate via message-passing, an implementation of the Actor model (it sounds like a similar model is planned for JS3).

Fortunately, until the point at which we reach convergence nirvana, developers can use abstraction layers (e.g. Dojo Storage) to avoid having to code to multiple implementations.

Update: There’s a great post by Aaron Boodman over at the Gears API Blog on exactly how the Gears team sees the relationship between Gears and HTML5, both now, and in the future. Here’s the money quote:

Gears aims to bring emerging web standards to as many devices as possible, as quickly as possible.
Aaron Boodman, Gears and Standards