6 ms·

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 cod

by ergo98 16y ago

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 Microsoft doesn't REALLY support either: Does IE9 have IndexedDB? Not that I'm aware of. Microsoft's angle regarding Web Databases was nothing more than "I don't know...that looks mighty uppity for a web app..." 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. Further, Chrome, Safari, Opera, other...none of them support IndexedDB, so as a standard it is effectively irrelevant. Presumably the W3C have decided to favour IndexedDB instead, which solves many of the same problems in a much more elegant, simple and well-specified fashion. Ha ha ha! The IndexedDB spec right now has incredible gaps that make it close to useless. The braintrust at Mozilla that are responsible for it can't stop themselves from saying "CouchDB" long enough to actually work on it, it seems. I think they got caught up in the whole NoSQL thing. So much so that they now seriously advocate that libraries should pop up inefficiently implementing SQL on top of IndexedDB, which is just saddening. But aside from that, rah!

henryprecheur 16y ago
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.
- rsanders 16y ago
  Where "better" doesn't mean "more efficient, more powerful, more understood, or more effective", but "more standard-y".
  - drivebyacct2 16y ago
    Why is that the correct interpretation of "better". That seems like the wrong sort of "better".
Groxx 16y ago
>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.
halo 16y ago
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-mode-and-progress-on-print-preview/ 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-the-html5-community.aspx 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-databases.aspx 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".
- drivebyacct2 16y ago
  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.
  - arethuza 16y ago
    Which is what Safari and Chrome already do - works perfectly well, even though the asynchronous API takes a wee bit of getting used to.
nl 16y ago
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-the-html5-community.aspx http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-t... [2]: http://dev.w3.org/2006/webapi/IndexedDB/ http://dev.w3.org/2006/webapi/IndexedDB/
- ergo98 16y ago
  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).
pornel 16y ago
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).
- sid0 16y ago
  Exactly. All proposed web standards require at least two implementations to become actual web standards. That was never going to happen with Web SQL.
sid0 16y ago
For any web standard to be valid there need to be two different implementations. There is no second implementation for Web SQL.

by ergo98 16y ago

henryprecheur 16y ago

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.

rsanders 16y ago
Where "better" doesn't mean "more efficient, more powerful, more understood, or more effective", but "more standard-y".
- drivebyacct2 16y ago
  Why is that the correct interpretation of "better". That seems like the wrong sort of "better".

Groxx 16y ago

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

halo 16y ago

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-mode-and-progress-on-print-preview/ 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-the-html5-community.aspx 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-databases.aspx 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".

drivebyacct2 16y ago
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.
- arethuza 16y ago
  Which is what Safari and Chrome already do - works perfectly well, even though the asynchronous API takes a wee bit of getting used to.

nl 16y ago

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-the-html5-community.aspx http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-t... [2]: http://dev.w3.org/2006/webapi/IndexedDB/ http://dev.w3.org/2006/webapi/IndexedDB/

ergo98 16y ago
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).

pornel 16y ago

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

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

sid0 16y ago

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