For the second category, IMHO, it may be better to focus on getting the right HTTP abstractions emulated locally for offline purposes. If people are going to need to upgrade their browsers for off-line use, then might as well provide them one that will allow them to run an “embedded REST server” within the browser. I mean let people write their own server emulation logic in JavaScript using whatever storage that’s available to them in the browser, whether it is key-value pair or SQLite or another, and serve offline requests over the same interface that the server does – HTTP and URL.

I have a proposal before the Webapps WG at W3C to consider adding JavaScript interceptors to enable various kinds of offline operations to take place without necessitating any standards about the SQL storage and access portion.

Here’s the URL for my blog post about the proposal and its comparisons to HTML5, Gears, and Dojo Offline: http://o-micron.blogspot.com/2009/04/bitsy-050-develop-seamlessly-on-lineoff.html

Key-pairs just don’t cut it for synchronizing complex sets of data between the client browser and a server-based database, especially when the application has an offline mode and updates, insertions and deletions must be submitted to the server DB when the client returns to an online state. This is not a theoretical situation I’m giving you. It’s an actual use case at the company I work for.

@Nicholas Orr:

The ability to store DB information on the browser is vital for business-oriented offline Web applications, so nobody’s going to wait 10 years for a standard before implementing such a feature. While a better standards would be preferred, I strongly suspect that the longer it takes to release a standard, the more likely it will be that the solutions provided by one or more vendors will either become the standard, make the standard irrelevant or delay the adoption of the standard significantly. Better a half-a**ed standard that everyone supports than a thoughtful, well-designed standard that no one supports.