As a relative late comer to HTML5 trying to catch up on a spec that spans over a 1000 pages is no mean feat, let alone the fact that the definition of what makes up HTML5 is covered across several specs (see previous blog on standards spaghetti). If you’ve been following this series then you’ll have worked out I have a few favourite features that I think will radically change the perception of web applications, and you guessed it HTML5’s support for database access is another.
The specification started out as early as 2006 with WebSimpleDB (aka WebSQL), and went as far as implementation into many browsers including webkit, Safari, Chrome and Firefox. From what I can find Oracle made the original proposal in 2009 and the W3C made a switch to Indexed DB sometime in 2010. Although Mozilla.org already had their own implementation using SQL-Lite, they too preferred IndexedDB). The current status as of April 2011 of the IndexedDB spec is that it is still in draft, and according to www.caniuse.com early implementations exist in Chrome 11 and Firefox 4. Microsoft have released a prototype on their html labs site at to show their current support .
Clearly it is not ready for live commercial applications in the short term, but it is certainly something worth keeping your eye on and to plan for. When an application requires more than simple key value pairs or requires large amounts of data, IndexDB should be your choice over HTML 5’s WebStorage api’s (localStorage and sessionStorage).
Next there are two API modes of interaction, Asynchronous and Synchronous API’s. As you would imagine synchronous API’s DO block the calling thread (i.e each call waits for a response before returning control and data). Therefore it follows that the asynchronous API’s do NOT block the calling thread. When using asynchronous API’s a callback function is required to respond to the events fired by the database after an instruction has been completed.
Both approaches provide API’s for opening, closing and deleting a database. Databases are versioned, and each database can have one or more objectstores. There are CRUD API’s for datastore access (put, get, add, delete) as well as API’s to create and delete index’s.
Access to the datastore is enveloped in transactions, and a transaction can be used to access multiple data stores, as well as multiple actions on a datastore.
It’s good to see early implementations and prototypes for IndexDB and whilst the date for finalising this spec is unclear, I for one will be monitoring it’s progress closely and waiting with baited breath for it’s finalisation.
Find your next job with computerworld UK jobs