Sqlite has been around for almost 15 years now. It's time to adopt it as a standard. Even if they're not satisfied with it, they can easily put a 'draft' stamp on it and provide people with a working, well-tested way to use it today. Firefox already has the support for it since your internal settings and favorites are also stored in guess what.... SQLite databases!
What's even more confusing is that Mozilla is actually listed on the Sqlite.org webpage as a sponsor, but they refuse to land it in Firefox. All because of hipster politics and creative arguments like the one above.
Sure it can use work. Migrations suck. But it will never evolve any further as long as they refuse to adopt it.
No, because the proposed spec did not actually specify the behavior in a way that was independently implementatble.
The spec did not specify the supported query language, either by simple reference to a specific version of the SQL standard (which would be problematic, because a complete and correct implementation of any, at least recent, version of the SQL standard is rare, and probably inappropriate for the use case), or by more complex reference-with-identified-exceptions, or by just listing out the supported features and expected behavior.
It was, therefore, not possible even in principle to have mutually-compatible, independent implementations (and all of the existing implementations just did "link to some version of SQlite and do whatever it does".)
> Sqlite has been around for almost 15 years now. It's time to adopt it as a standard.
Its a good, widely used, tool -- and one that is rapidly changing. But the whole point of web standards is to specify behavior in a way which permits mutually compatible, independent implementations. And WebSQLDB didn't do that, and didn't really seem to be progressing toward doing that.
> What's even more confusing is that Mozilla is actually listed on the Sqlite.org webpage as a sponsor, but they refuse to land it in Firefox.
SQlite is -- or has been, at least, not sure if it still is -- used in Firefox. What they haven't included in Firefox is a WebSQL database implementation, because they believe -- and rightly so -- that WebSQL database wasn't appropriate as a web standard, and didn't show any sign of heading toward something that would be appropriate as such a standard.
SQLite library is in public domain, has more lines of code test cases than lines of code C library code and its SQL API is stable. Plus the SQL language is well documented: https://www.sqlite.org/lang.html
W3C could also simply just fork SQLite at any time and modify the SQL dialect.
Mozilla and Oracle both are official gold sponsors of SQLite, both companies use the library in their own products though made a lot of effort to create IndexedDB and especially tried to deprecate WebSQL - nice job!
Microsoft has several embedded SQL libraries (JetBlue, JetRed, SQL Server Express) and it would be a piece of cake for them to modify the SQL parser a bit to the WebSQL SQL dialect.
The fact that SQLite is available is entirely irrelevant to any of this. The W3C can't just say "do it like SQLite does it" - that's not a standard. The WebSQL spec that exists says:
> User agents must implement the SQL dialect supported by Sqlite 3.6.19.
Unless someone actually sits down and goes through the standardisation process to define WebSQL properly, this is not the way to go, or the next thing will be "implement this tag like Firefox does".
Istill haven't seen any argument on why it isn't possible to freeze it at some point and agree on the fact that that's already an interoperable standard that works in the field right now.
This is IMO still an the result of a NoSQL biased group of people that decided to go another way for the sake of being cool. SQLite is specced and tested inside out and back and forth (LITERALLY!) You can write a spec on that better than you can write a spec on how IE 6 behaves.
There's nothing wrong with implementing SQLite next to IndexedDB, and its not like W3 is going to send the Internet Standards cops to bust the browser vendors that have.
OTOH, there is something wrong with standardizing "whatever the version of SQLite happens to be used in the most recent version of Chrome happens to do" in a W3C spec. Speccing out an API and a specific supported subset/dialect of SQL for WebSQL that could support multiple independent compatible implementations would be appropriate (and it could even be based closely on what a particular version of SQLite does) -- but no one involved was interested enough in doing that to actually, well, do it, and that's why WebSQL ended up in limbo.