4 ms·

Why does it matter to them that there's no competing spec Because ALL web standards are standards only because of the fact that there are MULTIPLE implementati

by sid0 16y ago

Why does it matter to them that there's no competing spec Because ALL web standards are standards only because of the fact that there are MULTIPLE implementations. This is a basic principle behind the Web, and making even a single exception leads to a dangerous slippery slope. It seems they're trying to run it into the ground because they don't control it No. because it didn't go through their proper procedure, whereby it must have a competitor. Yes. In the long term, not having another implementation is a dangerous sign -- it is a sign that developers are incapable of coming up with another implementation. What if SQLite can't be ported to some hypothetical architecture/stack in the future -- for example, a fully managed OS? What is the guarantee that someone will be able to come up with another implementation of the same spec which can run on that OS? At least with multiple implementations you know that the problem is tractable. Why? In what way is this helpful? It is helpful because it demonstrates long-term thinking. And if they're not being helpful, what's their purpose? To be dogmatic and prevent good ideas they didn't come up with from spreading? No, to think in the longer term than you do.

Groxx 16y ago
And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links) Similarly, there are plenty of implementations of SQL out there. They don't count?
- sid0 16y ago
  And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links) There's an early one in Firefox 4 beta right now [1], and an upcoming one in Chrome [2]. Microsoft will probably implement IndexedDB in a future version of IE [3]. (IndexedDB isn't a standard right now either, but it'll be on track to be one once two implementations are complete.) [1] https://wiki.mozilla.org/Firefox/Projects/IndexedDB https://wiki.mozilla.org/Firefox/Projects/IndexedDB [2] http://www.chromium.org/developers/design-documents/indexeddb http://www.chromium.org/developers/design-documents/indexedd... [3] 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... Similarly, there are plenty of implementations of SQL out there. They don't count? No, since none of them share all the peculiarities of SQLite. For example, SQLite doesn't have type checking, while most other SQL databases do.
  - Groxx 16y ago
    I don't think any browser shares all the peculiarities of any other browser. That's hardly an argument against there being a W3C spec for HTML, CSS, the DOM, or JavaScript. Why pick on SQL?
    - sid0 16y ago
      By "peculiarities" I didn't mean minor implementation differences but the major ideas behind the implementation. Be reasonable here -- the differences in implementation in the DOM between Gecko and WebKit (say) are trivial compared to "type checking" vs "lack of type checking". There's a bit of subjectivity involved, agreed, but I think any reasonable person would agree about the differences.
      - Groxx 16y ago
        There are indeed differences. Much greater with SQLite vs (most) other SQL engines. I still see it as killing something out of some ulterior motive rather than supporting something highly effective. SQLite exists because it has survived against many competitors for a long time. It's not like this is some new, untested thing that cropped up out of nowhere. edit: just realized there's a much stronger argument here. And a bigger threat. By not supporting WebDatabase, because the implementers all used SQLite, they've essentially guaranteed that they will never support an SQL-based database. Few are going to want to compete with SQLite on its own turf as an embedded database when it's already so optimized. Especially if they all have to agree on a spec similar to SQLite. SQLite isn't even all that poor of a match for a JS-interfaced database. JS is nearly as fast and loose with its types as SQLite, and the types that do exist are very close to what JS has.
        sid0 16y ago
        You still haven't answered what you're going to do if the current SQLite code simply can't run on a particular OS stack. There's no guarantee that every future stack will have a C compiler, or even allow C programs.

by sid0 16y ago

Groxx 16y ago

And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links) Similarly, there are plenty of implementations of SQL out there. They don't count?

sid0 16y ago
And the multiple implementations of IndexedDB are...? (don't actually know. If you do, I'd be interested in links) There's an early one in Firefox 4 beta right now [1], and an upcoming one in Chrome [2]. Microsoft will probably implement IndexedDB in a future version of IE [3]. (IndexedDB isn't a standard right now either, but it'll be on track to be one once two implementations are complete.) [1] https://wiki.mozilla.org/Firefox/Projects/IndexedDB https://wiki.mozilla.org/Firefox/Projects/IndexedDB [2] http://www.chromium.org/developers/design-documents/indexeddb http://www.chromium.org/developers/design-documents/indexedd... [3] 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... Similarly, there are plenty of implementations of SQL out there. They don't count? No, since none of them share all the peculiarities of SQLite. For example, SQLite doesn't have type checking, while most other SQL databases do.
- Groxx 16y ago
  I don't think any browser shares all the peculiarities of any other browser. That's hardly an argument against there being a W3C spec for HTML, CSS, the DOM, or JavaScript. Why pick on SQL?
  - sid0 16y ago
    By "peculiarities" I didn't mean minor implementation differences but the major ideas behind the implementation. Be reasonable here -- the differences in implementation in the DOM between Gecko and WebKit (say) are trivial compared to "type checking" vs "lack of type checking". There's a bit of subjectivity involved, agreed, but I think any reasonable person would agree about the differences.
    - Groxx 16y ago
      There are indeed differences. Much greater with SQLite vs (most) other SQL engines. I still see it as killing something out of some ulterior motive rather than supporting something highly effective. SQLite exists because it has survived against many competitors for a long time. It's not like this is some new, untested thing that cropped up out of nowhere. edit: just realized there's a much stronger argument here. And a bigger threat. By not supporting WebDatabase, because the implementers all used SQLite, they've essentially guaranteed that they will never support an SQL-based database. Few are going to want to compete with SQLite on its own turf as an embedded database when it's already so optimized. Especially if they all have to agree on a spec similar to SQLite. SQLite isn't even all that poor of a match for a JS-interfaced database. JS is nearly as fast and loose with its types as SQLite, and the types that do exist are very close to what JS has.
      - sid0 16y ago
        You still haven't answered what you're going to do if the current SQLite code simply can't run on a particular OS stack. There's no guarantee that every future stack will have a C compiler, or even allow C programs.