3 ms·
Or you know, they could have just used SQL.
by infinite8s 7y ago
Or you know, they could have just used SQL.
- kragen 7y agoImplementing SQL, even a reasonable SQL subset, is a lot harder than implementing IndexedDB.
- wayneftw 7y agoImplementing car engines is a lot harder than building wagons. So we should just go back to using wagons.
- kragen 7y agoWe definitely should not have standardized a worldwide standard design for car engines 40 years into the history of the automobile that everybody is required to implement bug-compatibly and nobody is allowed to change.
- orf 7y agoYes, the same as all the other databases that just “use SQL”. We all know how compatible they are.
- derefr 7y agoI said above: > SQLite's API (the C one, not the SQL one) To be clear of what I meant by this, it's not that SQLite has an API that you can use "instead of" SQL (like e.g. Z3 has a C API you can use "instead of" communicating via the LIB-SMT format) but rather that there are plenty of things you need to do to/in/with a DBMS that aren't covered by SQL itself, because SQL is designed around the needs of a client-server connection to a running steady-state database instance. In any case with a client-server RDBMS, where you'd need to manage it by connecting directly to the DBMS instance host and editing config files or using DBMS-package-supplied CLI commands, SQLite instead exposes these configuration and management operations through C API calls. Also, any "lower-level" operations that are part of the (proprietary) transport protocol for a client-server RDBMS, like statement parameter binding, delivery of notifications, or early termination of result streaming, are also done through the C API in SQLite, just like they're done through a protocol adapter library's API in a client-server RDBMS. For your application to create, manage, and use a SQLite database, it needs to use both of these kinds of APIs. Thus, for a web browser to usefully expose SQLite to Javascript, it would need to expose these APIs on the SQLite Database object (which is precisely what WebSQL does.) But neither the SQLite's "DB management" APIs, nor its "low-level protocol" APIs, have any standard keeping them stable in the way that SQL itself is stable. The API that SQLite exposes for this is precisely just "the API that SQLite exposes for this." It's made up, and nothing else implements it, because SQLite is the only embedded SQL RDBMS, so it's the only thing that needs an API like this, and so there's never been a need to unify SQLite's API with any other such API, and so there's never been a standards body created to accomplish such a task. Which is a problem, if you'd like you guarantee that an API function equivalent to e.g. "sqlite3_bind_blob64" is going to still be there tomorrow. WebSQL makes no such guarantee. If SQLite changes tomorrow and gets rid of that function, then WebSQL-the-"standard" would also change tomorrow and get rid of that function. (Or, a more likely example: if tomorrow SQLite found a security flaw in the semantics of sqlite3_prepare_v2(), and responded by implementing a sqlite3_prepare_v3() with different semantics and deprecating sqlite3_prepare_v2(); then WebSQL-the-"standard" would likely respond by making its single "prepare" API now suddenly obey the prepare_v3 semantics.) Thus, WebSQL is no standard at all.
- infinite8s 7y agoThank you, that's a very cogent reply to my rather flippant remark. Now I understand the reasoning behind not standardizing on WebSQL.