3 ms·

The web would be healthier if it had two competing APIs in SQLite and IndexedDB. Mozilla must come to the party and provide access to an embedding of SQLite.

The web would be healthier if it had two competing APIs in SQLite and IndexedDB. Mozilla must come to the party and provide access to an embedding of SQLite. It would be hubris to suggest they can design something better and to remove the alternative before they have done so.

arethuza 16y ago
I think I can see both sides of this argument - on one side there is the fact that SQLite is available, is a great bit of software and is already built into a number of browsers, on the the other hand it does seem slightly odd to have specification that references an implementation ("do whatever version X.Y.Z of SQLite did). If they supported both then everyone would probably use SQLite and the standard Web stack becomes directly dependent on a particular implementation of something - which I don't think has ever been the case before. Personally, I'd go with SQLite, preferably with a synchronous interface as well. But I can understand the reservations of those who don't.
- rfugger 16y ago
  Mozilla's plan is to implement IndexedDB on top of SQLite, and then encourage developers to re-implement SQL in Javascript on top of that. 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... Sounds to me like a ludicrous hoop to make people jump through just to avoid an ad-hoc standard based on an implementation.
  - jorangreef 16y ago
    Yes, except Mozilla have to yet to show that it can be done. They are yet to understand that IndexedDB does simply not provide enough low-level primitives to implement SQL let alone have even a chance of coming within 10 orders of magnitude of the performance of SQLite. There's a design flaw in IndexedDB, namely IndexedDB does not regard objects as opaque. This is the first thing you'd need (followed by variable length records) if you wanted to implement SQLite on IndexedDB. Ships will sail around the earth but the flat earth society will flourish.

arethuza 16y ago

I think I can see both sides of this argument - on one side there is the fact that SQLite is available, is a great bit of software and is already built into a number of browsers, on the the other hand it does seem slightly odd to have specification that references an implementation ("do whatever version X.Y.Z of SQLite did). If they supported both then everyone would probably use SQLite and the standard Web stack becomes directly dependent on a particular implementation of something - which I don't think has ever been the case before. Personally, I'd go with SQLite, preferably with a synchronous interface as well. But I can understand the reservations of those who don't.

rfugger 16y ago
Mozilla's plan is to implement IndexedDB on top of SQLite, and then encourage developers to re-implement SQL in Javascript on top of that. 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... Sounds to me like a ludicrous hoop to make people jump through just to avoid an ad-hoc standard based on an implementation.
- jorangreef 16y ago
  Yes, except Mozilla have to yet to show that it can be done. They are yet to understand that IndexedDB does simply not provide enough low-level primitives to implement SQL let alone have even a chance of coming within 10 orders of magnitude of the performance of SQLite. There's a design flaw in IndexedDB, namely IndexedDB does not regard objects as opaque. This is the first thing you'd need (followed by variable length records) if you wanted to implement SQLite on IndexedDB. Ships will sail around the earth but the flat earth society will flourish.