5 ms·

There are good reasons why work has stopped on the WebSQL specification — everybody was using SQLite, and the specification can't be tied so closely to a single

There are good reasons why work has stopped on the WebSQL specification — everybody was using SQLite, and the specification can't be tied so closely to a single implementation of SQL. The specification even has the line "User agents must implement the SQL dialect supported by Sqlite 3.6.19"[1]. 1. http://www.w3.org/TR/webdatabase/#web-sql http://www.w3.org/TR/webdatabase/#web-sql Edit: here is Mozilla's rationale for not supporting WebSQL: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

mmahemoff 12y ago
While that looks ridiculous at first glance, one of the important things about the HTML5 spec was reverse-engineering to describe what the browsers are actually doing. I'd be more worried if it says "the latest stable SQLite", but referring to a frozen version is only being honest about expectations. I believe SQLite caused issues with MS, but Mozilla was more philosophically opposed to SQL as being legacy tech. Which is understandable but unfortunate when the standard had momentum and SQL is so well-understood.
- jgraham 12y ago
  One of the things that's well understood about SQL is that interop is terrible. No one expects to write anything substantial using Postgres and be able to port it over to MySQL or MSSQL without a serious amount of effort. On the backend, that's more or less OK, although one of the value propositions of ORMs is that they make it somewhat easier to change databases later by reducing the amount of product-specific SQL that has to be rewritten. On the web, however, it's totally unacceptable. Sites are expected to keep working between multiple browsers and across multiple browser versions. To achieve that level of interop would have required someone to sit down and write a detailed specification of the dialect of SQL that should be supported on the web, and for browser vendors to take the time to implement it. In practice people weren't willing to spend the time doing either of those things; the level of buy-in was enough to fork sqlite but no higher. Eventually the web might get something like WebSQL. But the way it will happen will be for people to implement SQL in js on top of IndexedDB. If that proves popular but has issues (e.g. with performance) then there will be renewed impetus to do a proper job of a WebSQL specification.
  - kbenson 12y ago
    I fail to see how that's any different than the current case with JS and how we use shims to normalize the usage to a sane, concise API until it stabilizes (if it ever does). Do we really expect there won't be umpteen shims for WebSQL to normalize any syntax and feature inconsistencies?
  - brixon 12y ago
    No one expects to write something in Python and port it over to C# with a serious amount of effort either. I don't think changing databases is more common than changing programming languages.
    - hyperpape 12y ago
      Which is why web standards often specify javascript APIs, and don't generally say "this should be available in a language that's...well, mostly imperative or object oriented, and maybe there can be some functional features, I guess..."
  - qwerta 12y ago
    There are well respected standards such as SQL 92. They could also just take SQLite specification and use it. Many SQL databases support multiple SQL dialects.
frik 12y ago
SQLite implements the SQL-92 standard (http://en.wikipedia.org/wiki/SQL-92 http://en.wikipedia.org/wiki/SQL-92 , http://en.wikipedia.org/wiki/SQLite#Features http://en.wikipedia.org/wiki/SQLite#Features ). Firefox certainly ships with SQLite and even their IndexedDB implementation is based on top of it internally (the irony): https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU Microsoft has MS Access JetRed, MS Outlook JetBlue and SQL Express SQL Databases that ship already with Windows and/or Office and are SQL-92 compatible. It should be trivial for them to figure out which SQL DB engine would fit best and integrate it in IE 12.
- davidjohnstone 12y ago
  First sentence of http://en.wikipedia.org/wiki/SQLite#Features http://en.wikipedia.org/wiki/SQLite#Features : "SQLite implements most of the SQL-92 standard for SQL but it lacks some features."
  - deleted 12y ago
    [deleted]
    - fidotron 12y ago
      Easy example: write a webapp that relies on SQLite's lack of type safety then encounter a browser that implements your vision of SQL but using a type safe backend. It'll break. This is why for this it's important implementation and spec are separated. Further, the trend for in browser APIs is for them to be lower level than previously. (See also WebGL, asm.js etc.). You could build an SQL abstraction over IndexedDB if you really want SQL querying, but people have noticed that the killer property for in browser DB libs is going to be replication and syncing after having disconnected - something a traditional SQL DB is not going to help with. For this reason PouchDB is closer to the API devs will actually be using day-to-day in web apps.
- Pxtl 12y ago
  I assume that for an embedded DB, MS would be using a variant of Microsft Sql CE, which is their counterpart to SqlLite. And it's terrible.

mmahemoff 12y ago

While that looks ridiculous at first glance, one of the important things about the HTML5 spec was reverse-engineering to describe what the browsers are actually doing. I'd be more worried if it says "the latest stable SQLite", but referring to a frozen version is only being honest about expectations. I believe SQLite caused issues with MS, but Mozilla was more philosophically opposed to SQL as being legacy tech. Which is understandable but unfortunate when the standard had momentum and SQL is so well-understood.

jgraham 12y ago
One of the things that's well understood about SQL is that interop is terrible. No one expects to write anything substantial using Postgres and be able to port it over to MySQL or MSSQL without a serious amount of effort. On the backend, that's more or less OK, although one of the value propositions of ORMs is that they make it somewhat easier to change databases later by reducing the amount of product-specific SQL that has to be rewritten. On the web, however, it's totally unacceptable. Sites are expected to keep working between multiple browsers and across multiple browser versions. To achieve that level of interop would have required someone to sit down and write a detailed specification of the dialect of SQL that should be supported on the web, and for browser vendors to take the time to implement it. In practice people weren't willing to spend the time doing either of those things; the level of buy-in was enough to fork sqlite but no higher. Eventually the web might get something like WebSQL. But the way it will happen will be for people to implement SQL in js on top of IndexedDB. If that proves popular but has issues (e.g. with performance) then there will be renewed impetus to do a proper job of a WebSQL specification.
- kbenson 12y ago
  I fail to see how that's any different than the current case with JS and how we use shims to normalize the usage to a sane, concise API until it stabilizes (if it ever does). Do we really expect there won't be umpteen shims for WebSQL to normalize any syntax and feature inconsistencies?
- brixon 12y ago
  No one expects to write something in Python and port it over to C# with a serious amount of effort either. I don't think changing databases is more common than changing programming languages.
  - hyperpape 12y ago
    Which is why web standards often specify javascript APIs, and don't generally say "this should be available in a language that's...well, mostly imperative or object oriented, and maybe there can be some functional features, I guess..."
- qwerta 12y ago
  There are well respected standards such as SQL 92. They could also just take SQLite specification and use it. Many SQL databases support multiple SQL dialects.

frik 12y ago

SQLite implements the SQL-92 standard (http://en.wikipedia.org/wiki/SQL-92 http://en.wikipedia.org/wiki/SQL-92 , http://en.wikipedia.org/wiki/SQLite#Features http://en.wikipedia.org/wiki/SQLite#Features ). Firefox certainly ships with SQLite and even their IndexedDB implementation is based on top of it internally (the irony): https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU Microsoft has MS Access JetRed, MS Outlook JetBlue and SQL Express SQL Databases that ship already with Windows and/or Office and are SQL-92 compatible. It should be trivial for them to figure out which SQL DB engine would fit best and integrate it in IE 12.

davidjohnstone 12y ago
First sentence of http://en.wikipedia.org/wiki/SQLite#Features http://en.wikipedia.org/wiki/SQLite#Features : "SQLite implements most of the SQL-92 standard for SQL but it lacks some features."
- deleted 12y ago
  [deleted]
  - fidotron 12y ago
    Easy example: write a webapp that relies on SQLite's lack of type safety then encounter a browser that implements your vision of SQL but using a type safe backend. It'll break. This is why for this it's important implementation and spec are separated. Further, the trend for in browser APIs is for them to be lower level than previously. (See also WebGL, asm.js etc.). You could build an SQL abstraction over IndexedDB if you really want SQL querying, but people have noticed that the killer property for in browser DB libs is going to be replication and syncing after having disconnected - something a traditional SQL DB is not going to help with. For this reason PouchDB is closer to the API devs will actually be using day-to-day in web apps.
Pxtl 12y ago
I assume that for an embedded DB, MS would be using a variant of Microsft Sql CE, which is their counterpart to SqlLite. And it's terrible.