"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > SQLite is not an option because it performs poorly with Java and we want > our formats to work with other implementations, like JGit. That's why > we created reftable instead of using SQLite. Interesting. I would've thought it'd be a solved problem by now given the popularity of both SQLite and Java. I actually expected choosing a more common/standard file format would make life easier for hackers of alternative git implementations. Searching for `pure java sqlite' reveals some projects, but I'm not a Java user at all so can't comment on the quality of implementations: https://html.duckduckgo.com/html/?q=pure+java+sqlite Fwiw, the US Library of Congress has SQLite as a recommended data format for several years, now: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml Nowadays I'm more concerned about the continued relevance or even existence of the LoC than SQLite. > Also, in general, I'm not interested in being tied to a single > implementation. If the developers of SQLite decide to dramatically > change the license of all their code like Oracle did with Berkeley DB, > we're going to have a problem. Yes, we can use the older versions, but > we'd still need people to maintain the library and update it. Whereas we'd be implementing and maintaining yet another one-off data format from day one instead of waiting for an eventuality which may never come. SQLite 3 has far surpassed the stability and use of Berkeley DB; there's not a lot of similar formats that might replace it (e.g. GDBM, LMDB). So I'd expect there'd be no shortage of hackers able to maintain a usable fork if push comes to shove. Fwiw, I consider the proliferation of data formats and protocols the biggest threat to digital freedom and security. Even when the implementations are open source it feels like a huge drain to have to constantly deal reviewing/porting code to deal with more formats.
