3 ms·
What a bullshit reason. This is why we can’t have good things.
by garmaine 5y ago
What a bullshit reason. This is why we can’t have good things.
- detaro 5y agoIt'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 agoAh, 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 agoIt 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)