I guess I just disagree that it would have been good for Mozilla to fudge the standardization rules.
The rule of having multiple implementations is an important one.
And it might have been possible - surely Google and Microsoft, who supported IndexedDB, had the resource to write an alternative implementation. I don't know the history enough to know why they didn't.
I think I'm more cynical about the process than you are. From my point of view, the process has been intensely political from day one, with rules honoured mainly in the breach.
Has some very good details. And it's certainly funny to see what was said during the discussion with how things turned out in practice.
Edit: I'd sum it up as "Google and Apple argue for a solution that will work on mobile; Mozilla and Oracle don't care about mobile, are weirdly obsessed with the idea that developers hate SQL, and use political manoeuvring to win the fight". (Oracle's role in this seems especially odd, but perhaps they had some longer term strategy in mind.) In any case, in retrospect ignoring mobile was a bad idea, and ditching SQL seems to have had no real benefit.
That's a very misleading summary. Mozilla is rather clear that they don't want to spec on a specific version of SQLite. The one thing that is weird is Mozilla saying that developers want "anything but SQL", which sounds like BS. But even if they were in agreement that SQL was great, the simple fact that there's no independent implementations of SQLite 3.6.whatever's SQL dialect is good enough reason to not make it a standard.
It does show the total need for a fast, JITable intermediate language, and the silliness in not having one from the start, or at least long, long ago.
> Mozilla is rather clear that they don't want to spec on a specific version of SQLite
Not entirely true either. From the link:
> Hixie has said before he’s willing to fully spec the SQL dialect used by [WebSQL]. But since Mozilla categorically refuses to implement the
spec (apparently regardless of whether the SQL dialect is specified), he doesn’t want to put in the work since it would be a comparatively
poor use of time.
It's clear in the email thread that the "spec" world just be codifying exactly what that version of SQLite did. It's not likely they'd pick an existing SQL dialect that's compatible with SQLite, or they'd be essentially limited to that version of SQLite. Result is that you'd end up with the same problem and things would not really be compatible.
Even in that article, the a dev says he's queried the SQLite version in order to detect which exact FT options are available.
The argument for it is basically "eh but it's handy", ignoring the idea of the Web.
I didn't feel the need; it just brings the discussion back to my earlier comment upthread.
If you don't want to just use Sqlite (understandable), and you don't want to write something that is as good as Sqlite (also understandable), then you're going to have a crap database implementation. There's just not a lot of other options there. Jonas' comment just reiterates the lack of choices.
But given the three bad choices, the question does arise: Was IndexedDB really the best of a bad lot? In 2009, a lot of very optimistic things were said about IndexedDB performance, adoption, usage on mobile, developer acceptance. It's been 6 years, and I think it's safe to say that IndexedDB hasn't lived up to anyone's hopes.
Clearly it was dumb for people at Mozilla to take a bullet for Microsoft. But no matter -- I'm curious why you can't see past that and (also) hold Microsoft to account for rejecting WebSQL.
The rule of having multiple implementations is an important one.
And it might have been possible - surely Google and Microsoft, who supported IndexedDB, had the resource to write an alternative implementation. I don't know the history enough to know why they didn't.