Chrome 4 Now Supports the HTML 5 Web SQL Database API

Posted by Abel Avram on Feb 18, 2010

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Data Access ,

Architecture

Tags

Internet Explorer ,

Database ,

Chrome ,

HTML 5 ,

Firefox

Google has announced support for the HTML 5 Web SQL Database API, and others are likely to follow soon or have already started on support for this API. In the meantime, the completion of the specification is blocked because all the implementers involved have chosen to use SQLite as underlying database, and multiple independent implementations are required for standardization.

As part of HTML 5, the W3C organization is working on a draft of the Web SQL Database API, a specification which covers storing and accessing data through SQL. The SQL language dialect which is described in the documentation is that of SQLite 3.6.19. This API allows web pages to contain code that interacts with an embedded client database, which is useful for applications wanting to store data locally or for offline browsing.

Google has announced support for Web SQL Database in the latest production version of their browser, Chrome 4, based on SQLite. This is a move toward standardization considering Google has a Database API, also based on SQLite, in Gears. Through the Gears API, structured data storage was provided for all major browsers, including IE, Firefox, and Safari; however, Google has stopped developing Gears.

Firefox 3 has an embedded SQLite database which is currently used mostly for storing bookmarks and history, but it will probably add support for Web SQL Database API. Work is underway on WebKit, the rendering engine used by Safari, to make the Web Database API available to web workers. Nothing is currently known about Microsoft’s plans for IE and the HTML 5 database API.

While some companies have implemented the Web Database API and others are working on implementing it, the specification has reached a roadblock according to the draft because all interested parties have chosen to use SQLite:

This specification has reached an impasse: all interested implementers have used the same SQL backend (SQLite), but we need multiple independent implementations to proceed along a standardization path. Until another implementer is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to SQLite, which isn't acceptable for a standard. Should you be an implementer interested in implementing an independent SQL backend, please contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward.

Given this “impasse”, it remains to see if the standard will drive the implementation or if it will be the other way around. At present, it appears that Google has driven an increase in the pace of browser development, and none of the browser vendors are waiting for the standards to complete before implementing their own Web SQL Database API support.

1. Back to top

   Underway in WebKit?

   by Ivo Limmen

   Strange to read that WebKit is still developing this feature as Chrome uses WebKit.

   Reply

2. Back to top

   Re: Underway in WebKit?

   by Bart Guijt

   The regular 'async' API is in WebKit for two years IIRC, the recent 'synchronous' API is not. That part of the API would also benefit greatly by running in a web worker.

   Reply

3. Back to top

   there's always a roadblock if you want one...

   by Gabor Ratky

   I find it funny that the fact that everyone chose SQLite (a smart and logical move by everyone) is now blocking the standardization effort. Yes, it would be great to see the standard work well with multiple implementations but once in a lifetime, when everyone agrees on something, why not just be happy about it? Life would be a lot easier on the HTML5 <video> front as well if companies weren't fist fighting over H.264, Ogg and whatever else they come up with.
   
   Or maybe standardize the SQLite dialect as a 'portable SQL dialect' and get on with it.</video>

   Reply

4. Back to top

   Waiting for Microsoft

   by Tim Howland

   I'm sure Microsoft will just use Access, or embed excel, or something similarly inane.

   Reply

5. Back to top

   Re: Waiting for Microsoft

   by Jay Godse

   I bet that Microsoft will use SQLite. Their current problem is that Firefox, Chrome, and Safari have taken away enough market share that taking IE in a proprietary direction with respect to HTML5 storage could easily kill IE.
   
   

   I'm sure Microsoft will just use Access, or embed excel, or something similarly inane.

   Reply

6. Back to top

   Re: there's always a roadblock if you want one...

   by Stefan Wenig

   Not without irony. But if you think about it - when there's just one implementation, what problem would standardization solve?

   Reply

7. Back to top

   Re: Waiting for Microsoft

   by Dan Tines

   I bet that Microsoft will use SQLite. Their current problem is that Firefox, Chrome, and Safari have taken away enough market share that taking IE in a proprietary direction with respect to HTML5 storage could easily kill IE.
   

   
   
   Only when and if HTML 5 (and specifically the Database API) is relevant years from now.

   Reply

8. Back to top

   Re: Waiting for Microsoft

   by Venkatramanan Sastry

   Now that the MS SQL Server Express is free and is the desktop offering of their SQL Engine, it would be wise for Microsoft to use MS SQL Server Express.
   
   If I recollect correctly, they haven't been consistent with their approach when it comes to storage (Microsoft Outlook still uses a proprietary format for data storage).

   Reply

• Older >