There’s been a lot of interest around the Web Storage spec (formerly part of whatwg HTML5), which exposes a SQL database to web applications to use for data storage, both for online and offline use. It presents a simple API designed for executing SQL statements and reading result rows. But there’s an interesting problem with this; unlike the rest of the HtML5, this section defines a core piece of functionality in terms of an undefined chunk referenced as “SQL”.
The initial implementations of Web Storage are both based on SQLite, and expose the dialect of SQL understood by SQLite to web content. I’m actually a big fan of SQLite, and was one of the advocates for pulling it into the Gecko platform. However, SQLite implements a variant of SQL, with a number of deviations from other SQL engines, especially in terms of the types of data that can be placed in columns.
Web content that is created to use database storage with SQLite as the backing is unlikely to work with any other backend database. Similarly, if another database was chosen as a browser’s backing implementation, web content that works with it is unlikely to work with anything else. This is a serious interop problem, the root of which is that there really isn’t a useful core SQL standard. SQL92 is generally taken as a base, but is often extended or altered by implementations. Even beyond the parser issues (which could be resolved by defining a strict syntax to be used by Web Storage), the underlying implementation details will affect results.
So, the only option is for the Web Storage portion of the spec to state “do what SQLite does”. This isn’t specified in sufficient detail anywhere to be able to reimplement it from the documents, so it would be even worse — “do what this exact version of SQLite does”, because there are no guarantees that SQLite won’t make any incompatible changes. For example, a future SQLite 4 may introduce some changes or some new syntax which wouldn’t be supported by earlier versions. Thus, it requires every single browser developer to accept SQLite as part of their platform. This may not be possible for any number of reasons, not the least of which is it essentially means that every web browser is on the hook for potential security issues within SQLite.
Instead of all of this, I think it’s worth stepping back and consider exactly what functionality web developers actually want. It’s certainly much easier to say “well, server developers are used to working with SQL, so let’s just put SQL into the client”, but it’s certainly not ideal — most people working with SQL tend to end up writing wrappers to map their database into a saner object API.
This is a conversation that’s worth having, both to figure out what could be done about the issues with directly exposing SQL/SQLite, and also to step back and explore alternate approaches to getting the same functionality in web developers’ hands. The mozilla.dev.platform group is as good a place as any for this conversation, so please post any thoughts you may have there. Hixie rightfully points out that public-webapps is probably a better place for this discussion (which I wasn’t even subscribed to for some reason).