Frank Goossens' Twitterless twaddle
Archive for the ‘webdb’ tag
In a good old-fashioned rant, Sam Johnston, an Australian cloud computing specialist and technology lobbyist, took offense with Mozilla’s stand against webdb in the W3C html5 webapp spec working group. On Twitter he was even more candid, writing “The anti-SQL nazis are apparently causing some real problems for offline-enabled webapps”. Although there is a lot more to Mozilla’s objections then just “developers don’t want to do SQL”, he off course is right that the decision to freeze standardization-work on webdb and to look into an alternative (web simple db) is a serious slowdown.
That’s the bad news, but let me share some good news with you as well; you can do cross-browser persistent data storage right here, right now! All you need to build a html5 webdb-alternative is old-fashioned javascript arrays and objects and related functions, some json and last but not least Paul Duncan’s persistjs (don’t download it there though, use the more recent version in the repository instead), a little javascript library that goes a long way to provide precious cross-browser persistent storage.
Simplified, your offline-enabled webapp would have to;
- store data in an array (or in objects in an array)
- do CRUD using your standard javascript functions (you could turn to something like jlinq to do more advanced things)
- use JSON.stringify (native or from json2.js) to turn the ‘repository’ into a string
- store the resulting JSON-string with persistjs’s store.set
- close tab or browser
- retrieve JSON-string when user returns with store.get
- use JSON.parse to turn the string into an array
- go back to step (2)
As code is better then a numbered list, I’ve created TrappistDB, a -very simple- demo that can do CRUD on a small persistent dataset of beer Trappist-related information.
So there you have it, basic cross-browser (*) persistent data storage without html5 webdb. Just sprinkle some appcache-magic (adding Google Gears LocalServer-support is trivial) on top to store html, js, css, … in your browser and you have a fully offline-enabled webapp.
(*) tested successfully in Firefox 3.6b5, Safari 4.0.3, Chrome 3.0.195.38, IE8 and MSIE6 (with and without Gears), IE7, the Android 1.5 browser on my HTC Hero and in iPhone’s Mobile Safari. I’ve got some weird bug in Opera 10.10 that I can’t seem to iron out though, but feel free to tell me what stupid mistake I made.
HTML5’s WebDB is one of the building blocks to create offline-enabled webapps. It allows web applications to store data in a local database and it is as such an important part in Google’s push for mobile webapps as an alternative for native mobile apps. The spec (although not finalized) is already implemented in Safari, Safari Mobile and in the Android 2.0 browser.
So WebDB will take the world by storm, won’t it? Well, pretend you didn’t read the title of this post and let’s look at some excerpts of the meeting minutes of the W3 Web Applications Working Group Teleconference of 02 Nov 2009 for more info on the state of WebDB. Charles McCathieNevile (Opera) had some good news to share:
At opera, we implemented web db [...] it’s likely we will [ship it] as people have built on it
and Google’s Ian Fette joined in:
We’ve implemented WebDB … we’re about to ship it
So that’s great news, no? We can expect WebDB to arrive in Chrome and Opera! OK, so what about Firefox and MSIE? Microsoft, represented by Adrian Bateman, stated:
We don’t think we’ll reasonably be able to ship an interoperable version of WebDB
Well, that doesn’t really come as a surprise does it? No WebDB in MSIE, but surely Mozilla will support this great spec? But Jonas Sicking’s point of view might be slightly shocking to some:
We’ve talked to a lot of developers, the feedback we got is that we really don’t want SQL [...] I don’t think mozilla plans to ship it.
Sorry, come again? Does that mean that Firefox will never support window.openDatabase()? Nope, they probably won’t and they provide some valid concerns (see also Vladimir Vukićević’s blogpost) in a mailinglist-discussion between Mozilla and Apple-engineers shortly after the meeting minutes were published. Summarized and simplified their objections boil down to two issues;
- in order to have a webdb standard, you also have to specify (and standardize) the SQL-language to query that database, the question is what SQL-dialect to standardize on.
- as the current implementations are all SQLite-based (including Google’s and Opera’s), the spec would have to describe the very specific SQL-dialect that SQLite uses (and maybe even of a specific version of SQLite)
Although I doubt that web-developers don’t want to do client-side SQL at all, writing a spec that almost mandates the use of a specific version of a specific product (even if it’s open source) can indeed be hardly considered the goal of w3.org’s standards creation process.
So back to the drawing-board for yet another spec? Based on the webapp group’s meeting minutes, Web SimpleDB (or “Nikunj”, after the name of the Oracle-engineer behind the idea) is considered a worthy alternative by at least Mozilla, Opera and Microsoft. Let’s hope that a consensus, a finalized spec (it’s in draft now) and the first usable cross-browser implementations will arrive soon.
Off course there’s more than just html5 in this new Android version, here’s a short video showing some of the changes in Eclair:
A personal message for HTC to finish this blogpost: feel free to skip Android 1.6 to focus on using 2.0 as the basis for my Hero’s next rom update 
Almost the same functionality, but with a different API, how did they implement mobile Gmail? Well, Appcache (a.k.a. “offline web application”) seems to be implemented separately. That makes sense as defining which files can be stored locally is more or less a one-off job. But for more complex data-oriented offlining with a local database, Google created a wrapper-script that hides the Gears and HTML5-API’s and the underlying differences, thus offering a unified way to store and retrieve information from a local db. The code, including an example, can be found in WSPL’s svn-repository in Google Code.
Great stuff, those wrappers. But wouldn’t it be even greater if Google’s browsers would support the native html5-specs, so these stopgap solutions weren’t needed to start with?
The 
Google claims 
