Building notes, projects, and occasional rants

And now there are two

With the recent arrival of HTML5-style SQL access in Webkit, we now have two approaches to the problem of offline storage available to us.

Comparing the HTML5/Webkit version with the Google Gears version, personally I prefer the Webkit one due to the async nature of the API.

With Gears, database access is a synchronous operation that might delay a critical event-driven application. By making those operations async, your Javascript event handlers can fire off a couple of queries and keep on doing their work. As a side effect, it introduces some parallelism into JS without the beautiful heavyweights of Gears worker pools.

I didn't see it written yet, but I assume that the Webkit implementation also uses the SQLite database, same as Google Gears. It would make sense given that the whole CoreData API also uses it. It seems to me that SQLite is becoming the standard SQL engine for this kind of thing, and with the work Google is doing with it and the fts engine, it can only get better.

I think that having these tools in our toolbox before a standard is defined is essential to provide real-world feedback. Committee-based standards are rarely as good as market-driven ones.

One thing that we cannot stop from speculating about, is the reasons for this code to appear right now. The blog post mentions that it was mere excitement of a couple of engineers with the spec, and I can understand that. But in my mind, having a decent offline mode in Webkit is essential to a proper Web-based SDK for the iPhone.

Of course, database access is only one of the parts to make a decent offline mode. In Gears, you have two more tools: a local server and a worker pool. The worker pool is nice but not required for a offline mode. On the other hand, the local server is. So it would make sense to implement some sort of local/offline asset manager next.

Yet, the worker pool is much, much more fun to play with and it could be used even with online apps. So I hope to see that first.

This would be less important if Gears was already supported in Safari, but we are nowhere near that point right now. The choice of C++ for the core of Gears has been pointed out in the mailing list as the main sticky point regarding a WebKit version: C++ and Objective-C are not the best of friends.

In any case, this is a step in the right direction. I welcome this efforts of implementation prior to standardization. And its nice to have new toys to play with.