6 ms·

(Replying to this and other comments in unison) A SQL standard never precluded a separate filesystem access standard and implementing databases on top of it.

by yyyk 4y ago

(Replying to this and other comments in unison) A SQL standard never precluded a separate filesystem access standard and implementing databases on top of it. But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards - and require depending on WASM when WASM might have not been necessary.

acdha 4y ago
> But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards Web SQL was dropped for precisely this reason: > The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ Without a magic want to force multiple implementations, all of those web apps would have been tied to a single implementation anyway _and_ it would have been harder to update it so even after something was fixed you'd need to wait until the oldest browsers were updated before you could rely on it. That is possible, of course, but it's a recipe for problems with something like a SQL database.
- xenadu02 4y ago
  SQLite is the one project that deserves an exception. There is a near zero chance anyone else can do better with similar quality (and test coverage!) Sometimes you need to be pragmatic IMHO.
  - samwillis 4y ago
    SQLite fits one generic model, and is a row level data store. DuckDB is a column store, and other DBs are designed to operate for specific use cases. This is open to all options. The point is that SQLite is a brilliant genetic option, but should not be the only option. WASM and OPFS is the right route forward to enable application developers to use the best data store architecture for their use case. Even within SQLite there are extension that would never have been an available to WebSQL that with this design are.
    - treis 4y ago
      But we have 0 options now and 1 is better than 0.
  - acdha 4y ago
    I certainly would agree that SQLite is exemplary but consider how many different things are handled under the aegis of the W3C: if you allow one exception, then you will have other people saying their favorite thing should also have one.
    - josefx 4y ago
      So how many implementations of widevine are around? Web standards are well past the point where anyone involved could claim the procedural, moral or intellectual high ground.
      - acdha 4y ago
        The apparent inconsistency here is because you're misunderstanding what Wide Vine is: The standard is Encrypted Media Extensions: https://www.w3.org/TR/encrypted-media/ https://www.w3.org/TR/encrypted-media/ That provides a standard way for web developers to say “Our audio/video files are encrypted. Use this decoder to decrypt the bytes for playback.”. Wide Vine is a popular Content Decryption Module used by EME but it's not the only one (Apple devices use FairPlay, Microsoft ships PlayReady) and the standards process required interoperability to be demonstrated. Web SQL's standardization process halted precisely because nobody was interested in building a second implementation. If Web SQL had a second implementation, it could have been standardized just like EME was.
        deleted 4y ago
        [deleted]
  - sfink 4y ago
    sqlite> create table numbers (val int); sqlite> insert into numbers values (7); sqlite> insert into numbers values (8); sqlite> insert into numbers values (9); sqlite> insert into numbers values ("hi mom, I'm a number!"); sqlite> select * from numbers; 7 8 9 hi mom, I'm a number! I agree that SQLite is great, but do you really want to standardize on that behavior? People will write applications that insert 41 characters into a varchar(40). And they will care when their sites break when constraints start to be enforced.
- yyyk 4y ago
  This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the problem was already very well specified at the offline level. A simple SQL standard would therefore not have incurred an unnecessary dependency on SQLite (had WASM/filesystem existed at the time, I suspect we could have also supported Web SQL with it). -- Bugs of course, exist with IndexedDb as well and will exist with these new WASM implementation.
  - derefr 4y ago
    Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developing against is willing to expose—both in terms of features (guaranteed by the standard or not), and in terms of bugs. (Yes, those devs are doing a bad thing. They should only obey the letter of the standard, and not "look through" to what the implementation is doing. But we can't just intentionally break support for the stuff they build through this empirical-discovery-of-features-and-bugs process. That would just hurt the innocent users who just want to access their websites — which might very well be abandonware by the point that we discover and fix whatever standard-nonconformance bug such sites relied upon.) What we can do to control developer behavior, is to impose incentives. If there are multiple implementations of the standard in popular use in different browsers, each with different bugs, then developers will feel the need to support those different browsers, and so will test in them, find where the deviations from the standard cause breakage, and so end up coding portably. But if all the implementations in use in different browsers have the same bugs (perhaps because they're all actually the same implementation), then even supporting multiple browsers won't do anything to break people's assumption on those bugs; and so people will write brittle code that depends on exactly those bugs being present to work, and will break even if the platform implementor just upgrades the implementation to a newer version without the bug. This is the "bug-for-bug compatibility" that Microsoft worries so much about across Windows versions. It's a royal PITA to support, and W3C/WHATWG/etc have thusfar assiduously avoided allowing anything into the standards which has only one implementation, and therefore which devs could ever "lock onto" the bugs of with brittle implementations. --- Also, this ignores that most of the "pragmatics" of managing a SQL DBMS are not specified by the SQL standard. SQL is not as standard as people think it is! ANSI SQL is mostly concerned with specifying how DML queries work; the DDL stuff is almost entirely a mess of implementation-defined syntax that happens to share some conventions, but with no standards guarantees. Check this out: https://www.postgresql.org/docs/current/sql-createindex.html#id-1.9.3.69.9 https://www.postgresql.org/docs/current/sql-createindex.html... > CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard. Do you really want to expose a SQL API where you can't create indices, because there's no portable syntax for creating indices? Would such an API even be useful? If we really wanted a "web SQL API", the designers of said API couldn't just lean on the existing SQL standard; they would actually have to standardize what "web SQL" syntax is themselves — probably as a superset of ANSI SQL, but still laying out a bunch of additional requirements. It'd be similar in scope to WebGL. That's a big ask. And even if they did that, that'd likely mean that they'd end up with no existing implementations of the standard! (Because it's not like you'd want to lock in all of SQLite's nonstandard DDL syntax choices as "the" WebSQL syntax, right? You'd want to think these out "from first principles", considering what's most "implementation-neutral.")
skybrian 4y ago
A SQL-level standard wouldn't do much because different apps will be using different database schemas anyway. (It's similar to how two applications that both use JSON format usually aren't going to be compatible, because they use it to store different things.) Only generic, schema-independent database tools and libraries would be helped. For a portable application file format, you'd want to pick a SQL implementation (probably SQLite), decide on a schema, and probably wrap it in a library, but once you do that it could be used in multiple apps.

by yyyk 4y ago

acdha 4y ago

> But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards Web SQL was dropped for precisely this reason: > The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ Without a magic want to force multiple implementations, all of those web apps would have been tied to a single implementation anyway _and_ it would have been harder to update it so even after something was fixed you'd need to wait until the oldest browsers were updated before you could rely on it. That is possible, of course, but it's a recipe for problems with something like a SQL database.

xenadu02 4y ago
SQLite is the one project that deserves an exception. There is a near zero chance anyone else can do better with similar quality (and test coverage!) Sometimes you need to be pragmatic IMHO.
- samwillis 4y ago
  SQLite fits one generic model, and is a row level data store. DuckDB is a column store, and other DBs are designed to operate for specific use cases. This is open to all options. The point is that SQLite is a brilliant genetic option, but should not be the only option. WASM and OPFS is the right route forward to enable application developers to use the best data store architecture for their use case. Even within SQLite there are extension that would never have been an available to WebSQL that with this design are.
  - treis 4y ago
    But we have 0 options now and 1 is better than 0.
- acdha 4y ago
  I certainly would agree that SQLite is exemplary but consider how many different things are handled under the aegis of the W3C: if you allow one exception, then you will have other people saying their favorite thing should also have one.
  - josefx 4y ago
    So how many implementations of widevine are around? Web standards are well past the point where anyone involved could claim the procedural, moral or intellectual high ground.
    - acdha 4y ago
      The apparent inconsistency here is because you're misunderstanding what Wide Vine is: The standard is Encrypted Media Extensions: https://www.w3.org/TR/encrypted-media/ https://www.w3.org/TR/encrypted-media/ That provides a standard way for web developers to say “Our audio/video files are encrypted. Use this decoder to decrypt the bytes for playback.”. Wide Vine is a popular Content Decryption Module used by EME but it's not the only one (Apple devices use FairPlay, Microsoft ships PlayReady) and the standards process required interoperability to be demonstrated. Web SQL's standardization process halted precisely because nobody was interested in building a second implementation. If Web SQL had a second implementation, it could have been standardized just like EME was.
      - deleted 4y ago
        [deleted]
- sfink 4y ago
  sqlite> create table numbers (val int); sqlite> insert into numbers values (7); sqlite> insert into numbers values (8); sqlite> insert into numbers values (9); sqlite> insert into numbers values ("hi mom, I'm a number!"); sqlite> select * from numbers; 7 8 9 hi mom, I'm a number! I agree that SQLite is great, but do you really want to standardize on that behavior? People will write applications that insert 41 characters into a varchar(40). And they will care when their sites break when constraints start to be enforced.
yyyk 4y ago
This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the problem was already very well specified at the offline level. A simple SQL standard would therefore not have incurred an unnecessary dependency on SQLite (had WASM/filesystem existed at the time, I suspect we could have also supported Web SQL with it). -- Bugs of course, exist with IndexedDb as well and will exist with these new WASM implementation.
- derefr 4y ago
  Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developing against is willing to expose—both in terms of features (guaranteed by the standard or not), and in terms of bugs. (Yes, those devs are doing a bad thing. They should only obey the letter of the standard, and not "look through" to what the implementation is doing. But we can't just intentionally break support for the stuff they build through this empirical-discovery-of-features-and-bugs process. That would just hurt the innocent users who just want to access their websites — which might very well be abandonware by the point that we discover and fix whatever standard-nonconformance bug such sites relied upon.) What we can do to control developer behavior, is to impose incentives. If there are multiple implementations of the standard in popular use in different browsers, each with different bugs, then developers will feel the need to support those different browsers, and so will test in them, find where the deviations from the standard cause breakage, and so end up coding portably. But if all the implementations in use in different browsers have the same bugs (perhaps because they're all actually the same implementation), then even supporting multiple browsers won't do anything to break people's assumption on those bugs; and so people will write brittle code that depends on exactly those bugs being present to work, and will break even if the platform implementor just upgrades the implementation to a newer version without the bug. This is the "bug-for-bug compatibility" that Microsoft worries so much about across Windows versions. It's a royal PITA to support, and W3C/WHATWG/etc have thusfar assiduously avoided allowing anything into the standards which has only one implementation, and therefore which devs could ever "lock onto" the bugs of with brittle implementations. --- Also, this ignores that most of the "pragmatics" of managing a SQL DBMS are not specified by the SQL standard. SQL is not as standard as people think it is! ANSI SQL is mostly concerned with specifying how DML queries work; the DDL stuff is almost entirely a mess of implementation-defined syntax that happens to share some conventions, but with no standards guarantees. Check this out: https://www.postgresql.org/docs/current/sql-createindex.html#id-1.9.3.69.9 https://www.postgresql.org/docs/current/sql-createindex.html... > CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard. Do you really want to expose a SQL API where you can't create indices, because there's no portable syntax for creating indices? Would such an API even be useful? If we really wanted a "web SQL API", the designers of said API couldn't just lean on the existing SQL standard; they would actually have to standardize what "web SQL" syntax is themselves — probably as a superset of ANSI SQL, but still laying out a bunch of additional requirements. It'd be similar in scope to WebGL. That's a big ask. And even if they did that, that'd likely mean that they'd end up with no existing implementations of the standard! (Because it's not like you'd want to lock in all of SQLite's nonstandard DDL syntax choices as "the" WebSQL syntax, right? You'd want to think these out "from first principles", considering what's most "implementation-neutral.")

skybrian 4y ago

A SQL-level standard wouldn't do much because different apps will be using different database schemas anyway. (It's similar to how two applications that both use JSON format usually aren't going to be compatible, because they use it to store different things.) Only generic, schema-independent database tools and libraries would be helped. For a portable application file format, you'd want to pick a SQL implementation (probably SQLite), decide on a schema, and probably wrap it in a library, but once you do that it could be used in multiple apps.