News for hackers. Stuff that matters.
Re:SQLite as an Application File Format (2014) by me551ah on Saturday June 13, 2020 @03:31PM (#23512015)
The only thing stopping SQLite from becoming the primary application file format is browsers. Every single other client supports SQLite. Embedded, Mobile, Lightroom, Desktop Apps and Cross platform mobile frameworks have really good support for SQLite.
Re:SQLite as an Application File Format (2014) by HelloNurse on Saturday June 13, 2020 @04:52PM (#23512616)
On the one hand, browsers dislike access to files (regardless of format) for security reasons. On the other hand, browsers use SQLite a lot. For example Firefox uses SQLite at least for IndexedDB (various files) and for history and bookmarks (places.sqlite): https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_Ope...
Re:SQLite as an Application File Format (2014) by mbreese on Saturday June 13, 2020 @06:18PM (#23513293)
Wasn't there an effort a few years back to try to create a W3C standard for accessing data that stalled because all of the browsers used SQLite and no one wanted to create a different implementation? IIRC, the standard required two different implementations and SQLite was used by everyone?
Re:SQLite as an Application File Format (2014) by EvanAnderson on Saturday June 13, 2020 @07:54PM (#23513898)
You're think of WebSQL. My take on it dying was a combination of "key-value stores can replace relational semantics and key-value stores are cool", "only oldsters use SQL", and "wheel-reinventing is fun". The whole "we need multiple independent implementations" was a convenient excuse to kill it in my view.
Re:SQLite as an Application File Format (2014) by alexhutcheson on Saturday June 13, 2020 @07:58PM (#23513924)
Re:SQLite as an Application File Format (2014) by TheRealPomax on Saturday June 13, 2020 @03:36PM (#23512055)
Primary application file format for... what kind of files? Because it's certainly not going to (nor should it ever) replace hypertext documents.

Being able to load a read-only .sqlite database might seem cool, but I can't think of a single instance in which that's smaller and/or more efficient than calling data endpoints that use gzip/brotli for transport.

Or are you thinking "as replacement for IndexedDB"? In which case, hard agree but then it's an actual database, not used as file data container.