31 ms·

SQLite is extensively used in web browser codebases. If you check your Firefox profile, it's well-packed with SQLite databases.

• Someone 5y ago
  I’m fairly sure that refers to https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database: “Web SQL Database is a deprecated web browser API specification for storing data in databases that can be queried using SQL variant. The API is supported by Google Chrome, Opera, and the Android Browser. The W3C Web Applications Working Group ceased working on the specification in November 2010, citing a lack of independent implementations (i.e. using database system other than SQLite as the backend) as the reason the specification could not move forward to become a W3C Recommendation.”
  • garmaine 5y ago
    What a bullshit reason. This is why we can’t have good things.
    • detaro 5y ago
      It's sort-of misleading IMHO. A shared backend would be fine (i.e. I believe the independent IndexedDB implementations all end up putting stuff into sqlite, but nevertheless count as independent since they demonstrate that the API isn't tied to it), but the spec draft said > User agents must implement the SQL dialect supported by Sqlite 3.6.19. as the only definition on what's allowed SQL, which is a no-go for a spec. The authors could have provided a specification of a required SQL dialect that's sufficient to implement it from scratch/on top of another database, but decided to abandon the effort instead.
      • Taywee 5y ago
        Ah, I see. The wording on the Wikipedia page isn't as good as the wording on the specification draft itself: > This document was on the W3C Recommendation track but specification work has stopped. 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. It seems like they didn't just need a specified SQL dialect, but multiple actual implementations, but I might be reading into the wording incorrectly.
        • detaro 5y ago
          It would likely be necessary to have an independent interpreter for the SQL dialect at least, yes. I.e. I assume that something that parses the SQL from scratch and then down the line hands stuff to sqlite as the storage engine would qualify, since the SQL dialect is the point of contention. (The "multiple independent implementations" requirement is afaik also not 100% hard - if everyone agrees to ignore it, it can be ignored, but it's a strong objection if someone disagrees)
  • Taywee 5y ago
    I see, thanks. I don't totally agree, though. The comment implied that SQLite's test suite being proprietary is what "kept SQLite out of the browser" by preventing forks, when what kept SQLite out of the browser was just that there were no other high-quality embeddable SQL libraries. Perhaps the test suite being non-proprietary would have allowed for easier forking, but the lack of an available open test suite certainly doesn't *prevent* forks of a public domain codebase, and nothing prevents competing embedded SQL libraries other than the lack of motivation to compete with SQLite. Even if SQLite's test suite was open, I wouldn't see any big forks taking off, because why would you really want to build a competitor to something that's already super easy and free to use, extremely high quality, very high performance? What really is the drive? If SQLite ever does something the community really doesn't like, then a fork would be worth starting, but unless that happens, I don't see any point, and I really don't see that happening any time soon, given the consistent quality and power of SQLite.
    • ec109685 5y ago
      They don't allow pull requests could be one reason. E.g. if you wanted to take SQLite in a different direction. https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html