HTML5 gets a database

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)....

Share

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). The first important feature about IndexDB is that it is not a relational database but in fact an object store. Hence there are no tables, rows or columns and there is no SQL for querying the data. Instead data is stored as Javascript objects and navigated using cursors. The database can have indexes defined however. 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. At a very high level, there you have it, IndexDB is a feature that allows you to manage data in the browser. This will not only be useful for online applications (e.g. a server based warehouse could export data cubes for local access) but also for offline applications to hold data until a connection can be established. I’d fully expect a slew of Javascript frameworks to add value ontop of what the standards provide, indeed persistence.js is one such example. 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. http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/IndexedDB/ http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ http://trac.webkit.org/export/70913/trunk/LayoutTests/storage/indexeddb/tutorial.html

Find your next job with computerworld UK jobs