Posts Tagged ‘w3c’

HTML5 gets a database

June 9, 2011

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

HTML5 knows where you are!

May 12, 2011

A few years back I was deemed a heretic by many of my colleagues and friends  when I suggested that HTML5 will remove the need for writing many mobile applications. I was pummelled with questions like:

  • But how will they work offline?
  • Are you saying a browser user experience can rival a platform native one like Apples?
  • You do realise that most games require “threading” how you going to do that?
  • What about storing data locally, can you do that?

I was able to fend of most of these, but the one I couldn’t at the time was about accessing the device applications like Camera and GPS. Well things have moved on and whilst I am no longer deemed a heretic there are still some corridor’s whispering doubt.

One of the big features of mobile technology used by many apps is the phones location and location based services and application have already been through a huge hype cycle.

Under the catch-all banner of HTML5, although it is a separate subspec, the W3C Geo Location working group are making location based applications a reality for web developers. It has been around a while and hence is fairly mature and stable now.

A device (even a desktop) can provide location information in a number of ways:

  • IP Address (this is typically the location of the ISP rather than your machine, but ok if you simply want to check which country the user is in)
  • Cell Phone triangulation (only fairly accurate, very dependent on the phone signal so could be problematic in the countryside or inside buildings)
  • GPS (very accurate, takes longer to get location, dependant on hardware support and can be unreliable inside buildings)

Location data can also be simply user defined: however this is dependent on the user entering accurate information.

Of course one of the key concerns will be privacy but the spec covers this with an approach that the requires a user to give permission for location information to be passed to an application. Note the application can only access location information through the browser and not directly e.g. from the GPS device. Hence the browser enforces the user permissions for access.

The Geo Location API allow for both one off request to get the users current location or for repeated updates on the user’s position, developers write simple callback routines for both approaches. The key information provided includes: latitude, longitude and accuracy. Accuracy is a %value of how close the longitude and latitude values are to the user. Depending on the device you may also get additional information such and speed, heading (direction of travel) and altitude.

As per any quality application you process errors accordingly, especially responding to a failure to get hold of location data because of signal issues or other reasons. Hence retrieving location information is fairly simple, the real hardwork is in processing that information and that requires good old fashioned quality programming ;o)

This specification presents a huge opportunity for web developers to create applications once deemed only the domain of platform specific code, and I for one am very excited !

Microsoft wake up to smell the coffee

November 11, 2010

Another month, another confusing set of stories relating to Microsoft’s web framework Silverlight and the next generation mark-up language HTML5.

I wrote about the relationship previously, referring to Internet Explorer general manager Dean Hachamovitch’s suggestion that the future of the web is HTML5. More specifically, I questioned whether Microsoft’s support for HTML5 left Silverlight out in the cloud.

The answer for a few weeks, at least according to the team in Redmond, was at the centre of the next generation web. In a blog posting (see further reading, below), Microsoft’s director of product management for developer platforms Brad Becker stated that Microsoft remained committed to Silverlight – and that the framework extends the web by enabling scenarios that HTML does not cover.

That comment, in itself, was not surprising. HTML5 remains a work in progress, with developments on various platforms continuing to be developed. Silverlight, as Becker states in his own posting, is already installed on 600,000,000 desktops and devices.

But success is not just about numbers. Take the related area of mobile operating systems, where Symbian remains the leading mobile OS with about 40% of the market, according to analyst Gartner (see further reading).

Those figures, however, include the legacy of Nokia’s previous success. The smart phone market is leading to the ever-increasing growth – and inevitably the dominance – of Research in Motion, Apple and Android.

The same will be true in web development. Do not assume people will use a specific platform just because a provider has a ready-made user base. More to the point, Microsoft seems to be coming round to that way of thinking.

Bob Muglia, Microsoft’s head of servers and tools division, gave an interview at the company’s Professional Developers Conference and said that Silverlight was still “core” to Microsoft but the company was looking to other technologies to allow people to access online services (see further reading).

Muglia attempted to cool the situation in a blog posting (see further reading), suggesting his comment that the company’s Silverlight strategy had shifted was simply a comment on how the industry had changed. It was a suggestion that, rather then cool the situation, helped to add petrol to an already well-stoked fire.

Developers rounded on Muglia, posting comments on his blog which suggested they felt hurt and that Silverlight’s reputation had been left damaged: “The effort needed to restore our confidence in Silverlight is tantamount to unringing a bell,” suggested one poster.

HTML5 is a work in progress, but its progress is also startling. Non-believers – even at Microsoft’s Redmond HQ – are beginning to wake up and smell the coffee. Confusion reigns but sense, and HTML5, will win out in the end. Now somebody needs to pass the coffee cup to Adobe !

Further reading: