W3C Working Group Just Killed Web SQL Database
w3.org
w3.org
Presumably the W3C have decided to favour IndexedDB instead, which solves many of the same problems in a much more elegant, simple and well-specified fashion.
Having this on disconnected devices is a very common use case. These types of applications has been written in crummy VB6 or .NET code for a long time on handheld devices, etc. I guess they will continue to be written in it then.
Key/value stores and key/value stores with ponies and rainbows (NoSQL) is not a sufficently general solution to replace the relational model.
Why are you so wary of SQLite? As TCP/IP demonstrates, a rock solid implementation is a great help for standardization.
Which is one of the most tested, most utilized, most known pieces of code used among modern software. Saying "reference it" is entirely rational. And really the ludicrous notion that documenting its behaviors is unfathomably difficult is so asinine that it demolishes that line of argument.
neither Mozilla nor Microsoft supported it
Microsoft doesn't REALLY support either: Does IE9 have IndexedDB? Not that I'm aware of.
Microsoft's angle regarding Web Databases was nothing more than "I don't know...that looks mighty uppity for a web app..."
Mozilla is taking a very myopic, "high-road" approach that is similar to, and less justifiable, the whole h.264 debacle: Everyone loses, but someone gets to hold their head up high.
Further, Chrome, Safari, Opera, other...none of them support IndexedDB, so as a standard it is effectively irrelevant.
Presumably the W3C have decided to favour IndexedDB instead, which solves many of the same problems in a much more elegant, simple and well-specified fashion.
Ha ha ha!
The IndexedDB spec right now has incredible gaps that make it close to useless. The braintrust at Mozilla that are responsible for it can't stop themselves from saying "CouchDB" long enough to actually work on it, it seems.
I think they got caught up in the whole NoSQL thing. So much so that they now seriously advocate that libraries should pop up inefficiently implementing SQL on top of IndexedDB, which is just saddening.
But aside from that, rah!
For a web standard to succeed, you need either Mozilla or Microsoft support, preferably both. They have 75% of the browser market between them, so without either any standard is dead on arrival. Chrome, Safari and Opera individually do not have enough marketshare to be a significant influence on the takeup of web standards and still follow in the footsteps of the others. Incidentally, Chrome does support IndexedDB (http://peter.sh/2010/10/indexeddb-milestone-8-es5-strict-mod...).
Mozilla have made it clear they are supporting IndexedDB and not WebSQL. Microsoft have publicly posted remarks of support of IndexedDB on the IE blog (http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-t...) and Pablo Castro, an architect involved with web standards has publicly favoured IndexedDB over WebSQL (http://blogs.msdn.com/b/pablo/archive/2010/01/04/html5-does-...). It's not always easy to judge the inner workings of Microsoft, but I think it's a pretty strong hint as to what they are working on.
The IndexedDB spec seems relatively well-specified to me, and much more detailed than the WebSQL spec. Incidentally, the original authorship of WebSimpleDB was Nikunj Mehta, who was an Oracle employee at the time. The standard didn't originally come from any "braintrust at Mozilla".
I don't get it. If IE6 can be kept afloat by enterprise web apps that weren't designed for anything else, why can't there be web apps with offline features that only work with Chrome and Safari?
It'd be nice if you'd, you know, qualify this or something.
There is no standard. There is a proposed standard, but it's failed because it didn't have multiple implementations.
> and it's already been implemented by several
No, it has exactly one implementation: SQLite. SQLite-in-Safari and SQLite-in-Chrome obviously don't count as different implementations.
Anyway.
Yes, there is only one implementation, one standard, one non-W3C-spec. Why does it matter to them that there's no competing spec, when they could just support something that is already out there, and can be solved by pointing to http://www.sqlite.org/docs.html ? The API for accessing it is mindlessly simple and small, documenting that would take a day at worst.
It seems they're trying to run it into the ground because they don't control it, because it didn't go through their proper procedure, whereby it must have a competitor.
Why? In what way is this helpful? And if they're not being helpful, what's their purpose? To be dogmatic and prevent good ideas they didn't come up with from spreading?
---
edit:
>The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards. Led by Web inventor Tim Berners-Lee and CEO Jeffrey Jaffe, W3C's mission is to lead the Web to its full potential. Contact W3C for more information. (from http://www.w3.org/Consortium/)
How does trying to prevent it aid in "lead[ing] the Web to its full potential"?
Because ALL web standards are standards only because of the fact that there are MULTIPLE implementations. This is a basic principle behind the Web, and making even a single exception leads to a dangerous slippery slope.
It seems they're trying to run it into the ground because they don't control it
No.
because it didn't go through their proper procedure, whereby it must have a competitor.
Yes. In the long term, not having another implementation is a dangerous sign -- it is a sign that developers are incapable of coming up with another implementation. What if SQLite can't be ported to some hypothetical architecture/stack in the future -- for example, a fully managed OS? What is the guarantee that someone will be able to come up with another implementation of the same spec which can run on that OS? At least with multiple implementations you know that the problem is tractable.
Why? In what way is this helpful?
It is helpful because it demonstrates long-term thinking.
And if they're not being helpful, what's their purpose? To be dogmatic and prevent good ideas they didn't come up with from spreading?
No, to think in the longer term than you do.
Similarly, there are plenty of implementations of SQL out there. They don't count?
There's an early one in Firefox 4 beta right now [1], and an upcoming one in Chrome [2]. Microsoft will probably implement IndexedDB in a future version of IE [3]. (IndexedDB isn't a standard right now either, but it'll be on track to be one once two implementations are complete.)
[1] https://wiki.mozilla.org/Firefox/Projects/IndexedDB
[2] http://www.chromium.org/developers/design-documents/indexedd...
[3] http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-t...
Similarly, there are plenty of implementations of SQL out there. They don't count?
No, since none of them share all the peculiarities of SQLite. For example, SQLite doesn't have type checking, while most other SQL databases do.
I still see it as killing something out of some ulterior motive rather than supporting something highly effective. SQLite exists because it has survived against many competitors for a long time. It's not like this is some new, untested thing that cropped up out of nowhere.
edit: just realized there's a much stronger argument here. And a bigger threat.
By not supporting WebDatabase, because the implementers all used SQLite, they've essentially guaranteed that they will never support an SQL-based database. Few are going to want to compete with SQLite on its own turf as an embedded database when it's already so optimized. Especially if they all have to agree on a spec similar to SQLite.
SQLite isn't even all that poor of a match for a JS-interfaced database. JS is nearly as fast and loose with its types as SQLite, and the types that do exist are very close to what JS has.
If such a system exists, it won't be able to run the vast majority of stuff out there. Re-implementing SQLite will be the least of its concerns.
* of course we have multiple implementations of python: CPython, PyPy, IronPython...
* Python isn't a W3C standard, nor does it aim to be one.
Not standardizing on an implementation: makes sense. Refusing to standardize on an API until there are two+ implementations: ?
There are good reasons for this, like uncovering undocumented-but-essential behavior. I think if you are going to standardize an API you should have two implementations, but I also think it's reasonable to standardize a single implementation as long as it is licensed so that everyone can use it (e.g. SQLite).
Which is one of the most tested, most utilized, most known pieces of code used among modern software. Saying "reference it" is entirely rational. And really the ludicrous notion that documenting its behaviors is unfathomably difficult is so asinine that it demolishes that line of argument
The proposal wasn't to standardize on the SQLite implementation, it was to reverse engineer it and write a standards document from its behavior.
No one (including the maintainers of the Webkit-based implementations that had WebSQL) thought that was a good idea, but there weren't any good other proposals. Unlike WebSQL, IndexDB does have consensus amongst browser vendors. Microsoft haven't implemented it in IE9 yet, but are planning to support it [1]. IE9 does already support HTML5 localStorage, which is closely related to IndexDB (that close relationship is one of the reasons why IndexDB makes more sense to me that WebSQL)
As far as the NoSQL thing is concerned, I think it's interesting to note that IndexDB's semantics closely match those of BerkeleyDB, which started life in 1991. Work first started on IndexDB in 2006 [2], long before the term NoSQL was invented.
tldr; The SQLite software was never going to be the standard, rather one would be reverse engineered from it, and IndexDB predated (by far) the current trend towards "NoSQL" databases.
[1]: http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-t... [2]: http://dev.w3.org/2006/webapi/IndexedDB/
"As far as the NoSQL thing is concerned, I think it's interesting to note that IndexDB's semantics closely match those of BerkeleyDB, which started life in 1991. Work first started on IndexDB in 2006 [2], long before the term NoSQL was invented."
I don't think anyone believes that NoSQL is a new concept, regardless of the lineage of the current name (just as "AJAX" existed years before someone called it AJAX).
I was hesitating saying something to that effect in my comment, but seeing as someone else has broken the ice, what the hell:
This whole IndexedDB push by Mozilla has seemed a side-effect of the SQL/NoSQL hubbub, and not much else. There's legitimate use for IndexedDB, and it does a couple things better than WebDatabases do, and it's closer to writing JavaScript... but there's almost no reason to not implement WebDatabase by dropping an SQLite engine into your system. And why the hell couldn't they have picked something that already exists to a certain degree, rather than making everyone start from scratch in optimizations?
edit: to go a step further:
>Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.
They sound kinda like they're complaining about all this, in a "you'll see! You'll all see!" sort of way. I think it's a power-struggle thing; there's a standard on the web they don't and can't control, because everyone went ahead and agreed on something without them while they were busy making it way more opaque and complicated than it is / needs to be.
SQLite isn't quite SQL. It has weakly dynamically typed columns (will happily store strings in INT column), and ROWID/auto increment is icky (magic behavior with special-casing for backwards compatibility).
Sounds like Microsoft Windows to me :)
I think that SQLite is a really nice database. But just because SQLite would work in the browser, doesn't mean W3C shouldn't try to do something better.
>This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.
That notice has been up for quite a while now. They're just making it plainer that they've given up, because there's already a spec out there that they don't have control of.
Also, to perform a join in IndexedDB, you've gotta do it by hand, iterating over the results and merging data programmatically[1]. While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension, SQL is an incredibly capable language for interacting with a database, and has very mature and efficient implementations. Losing that would count as a massive loss to me. Why can't we have both? WebKit / Chrome is already going this route, as they have WebDatabase and recently implemented IndexedDB as well.
[1]: http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-web... example 4
That's because they want to support responsive applications. Javascript doesn't really have native concurrency operations, so the best (only?) way to do it is via async operations.
It's like XMLHttpRequest: Async only, which can be harder to program, but makes it a lot more robust.
Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.
I understand that having a synchronous API would mean more people would use it. But honestly, I see that as their problem. A fair number of queries, such as "select * from your_table where id = ?", are useful to have synchronous as an option, and should perform quickly enough to be invisible. And synchronous can easily be made asynchronous, but the other way around is essentially impossible without any Thread.join.
I definitely don't see this just suddenly evaporating or going unmaintained in those platforms.
I like it because the API is much more web-like than SQL. Others have other reasons to prefer it.
Also if IndexedDB has a "lifeless" spec, it might be because there's not much to discuss. Something simple and straightforward tends to requires much less discussion and debate, than something complex.
(disclaimer: I've come to quite like JS, it's made some of my experiments phenomenally simple. but it's weird.)
The web was built by taking existing systems, and cutting away at them until they were so simple they barely worked. But because they were simple they could spread.
IndexedDB isn't the simplest spec it could be (I think they could do-away with transactions if they were willing to require MVCC semantics) but it is admirably simple for a database.
That may be true in this specific case (I'm not saying either way), but it does not hold generally. For example, APIs involving directories and files are simpler than APIs involving inodes and blocks.
I have read the comments in Mozilla's thread http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... they clearly don't give a damn about what the users want.
They should have just agreed on a simple subset of SQL instead of going NoSQL, but apparently that wasn't good enough for them, waiting a decade more for something to store data in is probably better.
I personally love the concept of NoSQL, it's just that IndexedDB needs a few more years, which means it will probably even miss IE10.
Arguably, it's significantly safer than cookies, which are sent with every request (ie: Firesheep).
Although some might argue we're already there and that there's nothing stopping the deluge of user information.
Local storage wont go away. I hope Web SQL will be replaced by something "better" and more straightforward, A simple key-value database would be great.
That's exactly it:
I want to see what WebKit browsers are going to do. I use this in a couple of small HTML5 offline apps.
From practical perspective we would be better off with Web SQL DB. Functionally it addresses everything a developer needs to create offline HTML apps. API is not perfect but you can always improve that with small wrapper libraries (like JQuery improves DOM API). You can always easily implement IndexDB-like API on top off SQL if you really want that. The opposite is probably possible but much more difficult.
Also I think IndexDB might turn out to be yet another compatibility headache because everybody will be creating their own implementation (I'm pretty sure there will be at least 3 - Microsoft, Mozilla & Webkit). It's a speculation but most likely this wouldn't be an issue with Web SQL DB because everybody would just use the same SQLLite backend.
And worst of all, this is delaying progress of web applications. Lack of solid cross-browser client-side storage solution is the last big gap for next generation of web applications. If everybody had just agreed on SQLLite we could be there today... now it's still unknown when we will get there.
For a proposed web standard to become an actual web standard there need to be at least two implementations. This is a good, healthy thing. There was going to be no second implementation of Web SQL, so it was never going to become a standard.
Thankfully the app (a touchscreen kiosk which you'll see in a few museums in London) runs only in Chrome, so it'll be fine for as long as it's supported there.
if I want to store persist objects using localStorage, I'd convert them to JSON and store key-value. However I cannot store whole object hierarchy as it'll soon become an overkill.
so I store separate objects, and recreate relations upon retrieval manually. But I also need to maintain my own index - to know which objects I have stored under what keys.
As you see written in the spec, it was on the track to W3 Recommendation, but as every vendor who implemented it chose SQLite, there was little to do about it.
In other words, it isn't a "kill", just end of active maintainence. But spec as it is, is pretty solid. And WebSQL is here to stay in WebKit - there are just too many apps dependent on it to kill it. And no good reason to kill as there's no viable alternative on the horizon.
Summing up - WebKit (so iOS, Android and others) has it and will have it for quite a while, IE won't, FF won't too.
Perhaps someone will write JS library that implements IndexedDB on top of WebSQL (or vice-versa).
Instead they pushed/lobbied for the usual broken binding that is the very reason SQL is so contreversed: impedance mismatch.
Of course, hacking a javascript parser to introduce some SQL semantic in it is not exactly "easy"
Basically, the initiative was doomed from day one, what a waste of time...