W3C Working Group Just Killed Web SQL Database • Hacker News Board

Re: W3C Working Group Just Killed Web SQL Database

#51

Post by pornel » Fri, Nov 19, 2010, 10:09 AM UTC

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…

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

Re: W3C Working Group Just Killed Web SQL Database

#52

Post by pornel » Fri, Nov 19, 2010, 10:14 AM UTC

jasongullickson wrote: post #32

So what does this mean for browsers that support web SQL and apps that are built on it? Is it likely that Safari, Chrome, etc. will drop support for it before a viable alternative is avaliable?

It will be maintained until IndexedDB becomes viable.

Perhaps someone will write JS library that implements IndexedDB on top of WebSQL (or vice-versa).

Re: W3C Working Group Just Killed Web SQL Database

#53

Post by uriel » Fri, Nov 19, 2010, 11:06 AM UTC

Lets hope it stays dead, seems that we just dodged a pretty nasty bullet. IndexDB seems to also be ridiculously complex, but as wicked as most standards are anything is better than SQL.

Re: W3C Working Group Just Killed Web SQL Database

#54

Post by ergo98 » Fri, Nov 19, 2010, 12:43 PM UTC

nl wrote: post #27

ergo98 wrote: post #13

Earlier quoted context omitted.

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 S…

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

Re: W3C Working Group Just Killed Web SQL Database

#55

Post by pornel » Fri, Nov 19, 2010, 12:48 PM UTC

nex3 wrote: post #30

nl wrote: post #28

Earlier quoted context omitted.

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.

WorkerUI communication is asynchronous, and has additional limitations (only copying, only JSON-able data), so synchronous worker API in many cases would just shift complexity elsewhere.

Re: W3C Working Group Just Killed Web SQL Database

#56

Post by ihsw » Fri, Nov 19, 2010, 2:09 PM UTC

Groxx wrote: post #25

jfb wrote: post #21

Earlier quoted context omitted.

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

The issue would largely be storing sensitive data (I presume), namely personally identifiable information. Imagine all the user data being stored in a simple and quick API that advertisers (et al) can grab at, rather than having to scrape through HTML bits on a page. Now imagine malware spreading across the internet and frictionlessly gathering this data.

Although some might argue we're already there and that there's nothing stopping the deluge of user information.

Re: W3C Working Group Just Killed Web SQL Database

#57

Post by anarchitect » Fri, Nov 19, 2010, 2:29 PM UTC

ronaldj wrote: post #15

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

Well it's annoying that I've just finished coding a fairly complicated class this week which relies solely on Web SQL!

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.

Re: W3C Working Group Just Killed Web SQL Database

#58

Post by alkavan » Fri, Nov 19, 2010, 2:56 PM UTC

why would you write SQL with JavaScript? don't think that JavaScript yet at a point it can run heavy GUI element, handle AJAX, maybe Video or 3D and Query a database. JavaScript likes JSON very much, so all you need is just export your data with a language like PHP in JSON format, and handle it with JavaScript.

Re: W3C Working Group Just Killed Web SQL Database

#59

Post by Locke1689 » Fri, Nov 19, 2010, 3:10 PM UTC

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?

XSS and SOP disasters. Basically, everything that was broken about the web before, but more broken-y now. This of course applies to HTML5 local storage, too.

Re: W3C Working Group Just Killed Web SQL Database

#60

Post by zachrose » Fri, Nov 19, 2010, 3:33 PM UTC

halo wrote: post #24

ergo98 wrote: post #13

Earlier quoted context omitted.

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 suppo…

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