Hacker News Reader

The truth is the reason they pointed to SQLite is because the proposed API was so obscenely complicated that it was easier to point to a reference implementation than to accurately specify a standard, which points to a rather fundamental problem with the proposed standard: SQL is too damn complicated, and embedding it in browsers is a bad idea.

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

Why not just use SQLite? Write a small wrapper around it to isolate each website off on it's own database or set of databases. Each site corresponds to a SQLite user with a password that ONLY the browser knows.

Which is what Safari and Chrome already do - works perfectly well, even though the asynchronous API takes a wee bit of getting used to.

Because if everyone used SQLite there would be no second implementation, which is something that is necessary for a proposed standard to become an actual standard.

I believe you, especially as it makes a number of lines I've heard around this make more sense... but why? Especially in this case, where there is a standard and it's already been implemented by several? Is it just pedantry because they don't get to call the shots?

> where there is a standard

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.

It has one implementation implemented identically in more than one browser. SQLite. Which is a standard with an implementation to compare against.

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"?

Why does it matter to them that there's no competing spec

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.

And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links)

Similarly, there are plenty of implementations of SQL out there. They don't count?

And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links)

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 don't think any browser shares all the peculiarities of any other browser. That's hardly an argument against there being a W3C spec for HTML, CSS, the DOM, or JavaScript. Why pick on SQL?

By "peculiarities" I didn't mean minor implementation differences but the major ideas behind the implementation. Be reasonable here -- the differences in implementation in the DOM between Gecko and WebKit (say) are trivial compared to "type checking" vs "lack of type checking". There's a bit of subjectivity involved, agreed, but I think any reasonable person would agree about the differences.

There are indeed differences. Much greater with SQLite vs (most) other SQL engines.

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.

You still haven't answered what you're going to do if the current SQLite code simply can't run on a particular OS stack. There's no guarantee that every future stack will have a C compiler, or even allow C programs.

All that matters is the behavior, which SQLite has very well defined because it's a bit wonky out of maintaining backwards compatibility. Even the fundamental algorithms will still translate, so all that's needed is to compile it or something logically similar for the system with whatever compiler it allows. Heck, it'd probably be easier than implementing off an abstract spec, especially when you consider most of the optimizations will still translate but do not need to be discovered.

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.

That's a pre-open-source view of standards. We don't have multiple implementations of Python or Linux, yet they can be widely relied on.

It's the current W3C view of standards. Also

* of course we have multiple implementations of python: CPython, PyPy, IronPython...

* Python isn't a W3C standard, nor does it aim to be one.

Maybe W3C should change, rather than remaining stuck in the early 90s.

Well, I think having two implementations is necessary for a "standard" to actually truly be one, because if there's just one then you might as well be standardizing on the implementation rather than on the spec. I don't agree with standardizing on implementations in principle.

Hardly. An API can exist entirely without implementation, and pulling an API from an implementation doesn't need to expose any details of the implementation. That's kind of the point of an API - it's an abstraction. And what are the specs, if not APIs?

Not standardizing on an implementation: makes sense. Refusing to standardize on an API until there are two+ implementations: ?

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

> 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

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?

IE6's hanging around isn't looked at as a good thing.

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.

It'd be nice if you'd, you know, qualify this or something.

The most complex part of Web SQL effectively amounted to "Whatever SQLite implemented"

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/

Hi there, nl.

"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 think they got caught up in the whole NoSQL thing.

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.

Because there is only one implementation, no matter how good it is, websites would end up relying on every bug and quirk in SQLite.

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

Exactly. All proposed web standards require at least two implementations to become actual web standards. That was never going to happen with Web SQL.

Which is one of the most tested, most utilized, most known pieces of code used among modern software.

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.

Where "better" doesn't mean "more efficient, more powerful, more understood, or more effective", but "more standard-y".

Why is that the correct interpretation of "better". That seems like the wrong sort of "better".

For any web standard to be valid there need to be two different implementations. There is no second implementation for Web SQL.