3 ms·

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded

by frik 12y ago

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!) * Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog). Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL. To sum up, NoSQL has it's place and SQL has one too. We had this discussion already this week, hopefully W3C board members and Mozilla devs read this: https://news.ycombinator.com/item?id=9082847 https://news.ycombinator.com/item?id=9082847

thristian 12y ago
> The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Nobody ever said WebSQL was intended to require a specific version of SQLite. But nearly every browser would have used SQLite, and experience has shown that when you expose functionality to the web, sites start depending on specific implementation quirks - check out all the gibberish people used to feed to IE6's CSS parser to trick it into behaving. Also, note that SQLite is not what most people think of when they talk about SQL databases, if only because of its very "manifest typing". Maybe SQL92 is flexible enough to permit such things, but code written for SQLite is very likely to break horribly on other SQL implementations.
- frik 12y ago
  * There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020 http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92 http://en.wikipedia.org/wiki/SQL-92 * Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim. Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.
  - dragonwriter 12y ago
    > SQL-92 was the third revision of the SQL database query language. And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.
  - bad_user 12y ago
    Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser. > everyone else would use SQLite anyway That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test. > One could use a shim Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.
    - empthought 12y ago
      > unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser. You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?
dragonwriter 12y ago
> The argument that WebSQL was tailored to a specific SQLite version is nonsense. No, the idea that WebSQLDB was not tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]: User agents must implement the SQL dialect supported by Sqlite 3.6.19. > SQLite supports the official SQL92 standard SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19. [0] http://www.w3.org/TR/webdatabase/#databases http://www.w3.org/TR/webdatabase/#databases
- frik 12y ago
  Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Richard Hipp, the creator of SQLite, stated that the dialect won't change (removing syntax) in SQLite v3 during the WebSQL W3C standardization in the mailing list. About 95% of all mobile devices already support WebSQL (iOS & Android & WindowsPhone (via official Microsoft sponsored extension)). And all desktop Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11 and Firefox/FirefoxOS.
  - dragonwriter 12y ago
    > Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Everyone does not know this. Some people believe this, other people believe it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19". You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.
  - bad_user 12y ago

by frik 12y ago

thristian 12y ago

> The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Nobody ever said WebSQL was intended to require a specific version of SQLite. But nearly every browser would have used SQLite, and experience has shown that when you expose functionality to the web, sites start depending on specific implementation quirks - check out all the gibberish people used to feed to IE6's CSS parser to trick it into behaving. Also, note that SQLite is not what most people think of when they talk about SQL databases, if only because of its very "manifest typing". Maybe SQL92 is flexible enough to permit such things, but code written for SQLite is very likely to break horribly on other SQL implementations.

frik 12y ago
* There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020 http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92 http://en.wikipedia.org/wiki/SQL-92 * Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim. Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.
- dragonwriter 12y ago
  > SQL-92 was the third revision of the SQL database query language. And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.
- bad_user 12y ago
  Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser. > everyone else would use SQLite anyway That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test. > One could use a shim Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.
  - empthought 12y ago
    > unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser. You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?

dragonwriter 12y ago

> The argument that WebSQL was tailored to a specific SQLite version is nonsense. No, the idea that WebSQLDB was not tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]: User agents must implement the SQL dialect supported by Sqlite 3.6.19. > SQLite supports the official SQL92 standard SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19. [0] http://www.w3.org/TR/webdatabase/#databases http://www.w3.org/TR/webdatabase/#databases

frik 12y ago
Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Richard Hipp, the creator of SQLite, stated that the dialect won't change (removing syntax) in SQLite v3 during the WebSQL W3C standardization in the mailing list. About 95% of all mobile devices already support WebSQL (iOS & Android & WindowsPhone (via official Microsoft sponsored extension)). And all desktop Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11 and Firefox/FirefoxOS.
- dragonwriter 12y ago
  > Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Everyone does not know this. Some people believe this, other people believe it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19". You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.
- bad_user 12y ago