Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C Working Group Just Killed Web SQL Database

w3.org

Post reply on HN
Print view View original

81–87 of 87 posts

Re: W3C Working Group Just Killed Web SQL Database

#81

Post by sid0 »

Groxx wrote: post #80
sid0 wrote: post #79

Earlier quoted context omitted.

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.mozill…

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.

Re: W3C Working Group Just Killed Web SQL Database

#82

Post by Groxx »

sid0 wrote: post #81
Groxx wrote: post #80

Earlier quoted context omitted.

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.

Re: W3C Working Group Just Killed Web SQL Database

#83

Post by Groxx »

sid0 wrote: post #76
wmf wrote: post #74

Earlier quoted context omitted.

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

Re: W3C Working Group Just Killed Web SQL Database

#84

Post by wmf »

Groxx wrote: post #83
sid0 wrote: post #76

Earlier quoted context omitted.

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

Re: W3C Working Group Just Killed Web SQL Database

#85

Post by sid0 »

Groxx wrote: post #82
sid0 wrote: post #81

Earlier quoted context omitted.

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…

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.

Re: W3C Working Group Just Killed Web SQL Database

#86

Post by ficeto »

So reading all the comments I see that most "against" are because "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." WTF? Do we need to implement MySQL, PGSQL or MSSQL to get a chance of having SQL in our browsers? Does that sound stupid only to me? Is Mozilla trying to follow the "success" of IE? Who pays W3C? Why do they play like the God of Web? And why can't we have both? I certainly don't want to ever use IndexedDB if I have and SQL option.

Re: W3C Working Group Just Killed Web SQL Database

#87

Post by Groxx »

sid0 wrote: post #85
Groxx wrote: post #82

Earlier quoted context omitted.

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…

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.

Post reply on HN