BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Chrome 4 Now Supports the HTML 5 Web SQL Database API

by Abel Avram on Feb 18, 2010 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Underway in WebKit? by Ivo Limmen

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

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.

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>

Waiting for Microsoft by Tim Howland

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

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.

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?

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.

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT