7 ms·

It's unfortunate most of this was debated at the beginning of all the hype around NoSQL data stores. It would be some work, but still be relatively trivial to

by batbomb 13y ago

It's unfortunate most of this was debated at the beginning of all the hype around NoSQL data stores. It would be some work, but still be relatively trivial to build a query spec, probably based off of SQL 92, and a basic type system spec (Strings, numbers, and dates are the bulk of it), and then an implementation of everything else. Facebook did it with Presto, although they haven't finished the DML part of it. Reading the emails, I get the feeling most of the people involved didn't have as much experience with databases as they probably should have in order to make a truly informed decision.

TazeTSchnitzel 13y ago
They could have defined a subset of SQLite which you could implement without needing SQLite.
- frenchy 13y ago
  But if everyone used the same buggy implementations there would still be a problem. Web developers usually write for the implementation, not the spec.
pornel 13y ago
The problem is that all pages aren't written to the spec, they're written to work with implementations. When there's only one implementation (that authors care about), then every quirk, bug and accidental misfeature can be depended upon, and SQLite has plenty of those ("FLOATING POINT" parsed as "INT", magic of ROWID, the lax type system even more forgiving than PHP, etc.) If there was another implementation then lack of overlap in quirks/bugs would prevent authors from depending on them (e.g. if you wrote something stupid then it'd work in one browser, but not the other). ASCII venn diagram of 2 implementations: { bugs1 ( usable standard } bugs2 ) ASCII venn diagram of all browsers just shipping same Sqlite: {( usable: standard and all bugs })
- nolanl 13y ago
  That's a good point, and one I could have added to the post. There are bugs in Web SQL, but they're largely the same on both Chrome and Safari. IndexedDB is trickier, because the bugs are all different between Firefox, IE, and Chrome. Again, another situation where libraries can help out. Although in general, it's sad that the "independent implementations" mantra basically guarantees a lack of consistency across browsers. It's like we only have a choice between "pointing to a pile of C code" or ending up with a pile of browser bugs. Maybe the W3C could write acceptance tests to go alongside the specs.
  - pcwalton 13y ago
    > Maybe the W3C could write acceptance tests to go alongside the specs. Like these? :) https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests
    - nolanl 13y ago
      Heh, I learned a thing about a thing! :) Curious to know how so many quirks slipped through, though. Maybe I should do a PR on the tests for bugs that the browser vendors might not know about, e.g. https://gist.github.com/nolanlawson/8330172 https://gist.github.com/nolanlawson/8330172.

by batbomb 13y ago

TazeTSchnitzel 13y ago

They could have defined a subset of SQLite which you could implement without needing SQLite.

frenchy 13y ago
But if everyone used the same buggy implementations there would still be a problem. Web developers usually write for the implementation, not the spec.

pornel 13y ago

The problem is that all pages aren't written to the spec, they're written to work with implementations. When there's only one implementation (that authors care about), then every quirk, bug and accidental misfeature can be depended upon, and SQLite has plenty of those ("FLOATING POINT" parsed as "INT", magic of ROWID, the lax type system even more forgiving than PHP, etc.) If there was another implementation then lack of overlap in quirks/bugs would prevent authors from depending on them (e.g. if you wrote something stupid then it'd work in one browser, but not the other). ASCII venn diagram of 2 implementations: { bugs1 ( usable standard } bugs2 ) ASCII venn diagram of all browsers just shipping same Sqlite: {( usable: standard and all bugs })

nolanl 13y ago
That's a good point, and one I could have added to the post. There are bugs in Web SQL, but they're largely the same on both Chrome and Safari. IndexedDB is trickier, because the bugs are all different between Firefox, IE, and Chrome. Again, another situation where libraries can help out. Although in general, it's sad that the "independent implementations" mantra basically guarantees a lack of consistency across browsers. It's like we only have a choice between "pointing to a pile of C code" or ending up with a pile of browser bugs. Maybe the W3C could write acceptance tests to go alongside the specs.
- pcwalton 13y ago
  > Maybe the W3C could write acceptance tests to go alongside the specs. Like these? :) https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests
  - nolanl 13y ago
    Heh, I learned a thing about a thing! :) Curious to know how so many quirks slipped through, though. Maybe I should do a PR on the tests for bugs that the browser vendors might not know about, e.g. https://gist.github.com/nolanlawson/8330172 https://gist.github.com/nolanlawson/8330172.