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

21–30 of 87 posts

Re: W3C Working Group Just Killed Web SQL Database

#21

Post by jfb »

Groxx wrote: post #17
jfb wrote: post #8

Why, again, was this needed? HTML5 is already looking like a security and management shitstorm; anything that makes it simpler is fine by me.

How is a domain-locked local SQL database a security shitstorm?

I suppose I'm just jumpy because of the lack of granularity in user control over local storage, and wary of the eptitude of the browser vendors, and in favor of fewer, smaller features. After reading the inept IndexedDB thing, however, it seems like the wrong local storage mechanism is going to get it in the neck.

Re: W3C Working Group Just Killed Web SQL Database

#22

Post by jamesaguilar »

jchrisa wrote: post #3

This spec isn't the only game for offline storage. IndexedDB is the favored replacement: http://www.w3.org/TR/IndexedDB/ I like it because the API is much more web-like than SQL. Others have other reasons to prefer it.

For someone unfamiliar with the term, what does "web-like" mean?

Re: W3C Working Group Just Killed Web SQL Database

#23

Post by bphogan »

ronaldj wrote: post #15

Am I the only one that's sad about this?

No, in fact I'm mighty upset about this and have been for some time, mainly cos the damn thing isn't vaporware. It exists in Safari and Chrome, whereas IndexedDB works nowhere yet but "sounds neat."

I want to see what WebKit browsers are going to do. I use this in a couple of small HTML5 offline apps.

Re: W3C Working Group Just Killed Web SQL Database

#24

Post by halo »

ergo98 wrote: post #13
halo wrote: post #7

Probably a good thing. The most complex part of Web SQL amounted to "Whatever SQLite implements", neither Mozilla nor Microsoft supported it making the standard effectively irrelevent, and I remain thoroughly unconvinced that providing an extremely thin JavaScript API to an SQL-driven database is an elegant solution to this particular problem. Presumably the W3C have decided to favour IndexedDB instead, which solves…

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. neither Mozilla nor Microsoft supported it…

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

Re: W3C Working Group Just Killed Web SQL Database

#25

Post by Groxx »

jfb wrote: post #21
Groxx wrote: post #17

Earlier quoted context omitted.

How is a domain-locked local SQL database a security shitstorm?

I suppose I'm just jumpy because of the lack of granularity in user control over local storage, and wary of the eptitude of the browser vendors, and in favor of fewer, smaller features. After reading the inept IndexedDB thing, however, it seems like the wrong local storage mechanism is going to get it in the neck.

You've got just as much control. Grab the console and 'drop table' - all that data, gone. You can even trash all the databases in most browsers pretty simply. And restrict their size. The difference is that client-side JavaScript becomes useful with a large-ish local storage.

Arguably, it's significantly safer than cookies, which are sent with every request (ie: Firesheep).

Re: W3C Working Group Just Killed Web SQL Database

#26

Post by Groxx »

jamesaguilar wrote: post #22
jchrisa wrote: post #3

This spec isn't the only game for offline storage. IndexedDB is the favored replacement: http://www.w3.org/TR/IndexedDB/ I like it because the API is much more web-like than SQL. Others have other reasons to prefer it.

For someone unfamiliar with the term, what does "web-like" mean?

I'll be obtuse, and claim it means "JavaScript-like". You know, multiple "truthy" values, the inability to detect the difference between arrays and objects, a weird mashup of OO and functional abilities, `=== undefined` but `isNaN()`, and no real difference between integers and floats, and all the math weirdness that goes with them. Browsers implementing the same thing different ways, interacting with a system (the DOM) that's the same but different everywhere, and patched together by multiple, usually-mutually-exclusive libraries that everyone uses instead of the actual language.

(disclaimer: I've come to quite like JS, it's made some of my experiments phenomenally simple. but it's weird.)

Re: W3C Working Group Just Killed Web SQL Database

#27

Post by nl »

ergo98 wrote: post #13
halo wrote: post #7

Probably a good thing. The most complex part of Web SQL amounted to "Whatever SQLite implements", neither Mozilla nor Microsoft supported it making the standard effectively irrelevent, and I remain thoroughly unconvinced that providing an extremely thin JavaScript API to an SQL-driven database is an elegant solution to this particular problem. Presumably the W3C have decided to favour IndexedDB instead, which solves…

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. neither Mozilla nor Microsoft supported it…

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/

Re: W3C Working Group Just Killed Web SQL Database

#28

Post by nl »

Groxx wrote: post #10

Not quite, methinks: > 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…

While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension

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.

Re: W3C Working Group Just Killed Web SQL Database

#29

Post by [deleted] »

Groxx wrote: post #26
jamesaguilar wrote: post #22

Earlier quoted context omitted.

For someone unfamiliar with the term, what does "web-like" mean?

I'll be obtuse, and claim it means "JavaScript-like". You know, multiple "truthy" values, the inability to detect the difference between arrays and objects, a weird mashup of OO and functional abilities, `=== undefined` but `isNaN()`, and no real difference between integers and floats, and all the math weirdness that goes with them. Browsers implementing the same thing different ways, interacting with a system (the D…

[deleted]

Re: W3C Working Group Just Killed Web SQL Database

#30

Post by nex3 »

nl wrote: post #28
Groxx wrote: post #10

Not quite, methinks: > 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…

While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension 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.

> Javascript doesn't really have native concurrency operations

Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.

Post reply on HN