There's a couple of reasons:
* As for the rust bindings: they're sub-par to rusqlite, though
rusqlite is amazing. Even libsql-server uses rusqlite over their own
bindings. The bindings are missing features such as update hooks
and the hard-coded execution model suffers from lock congestion.
* We've fixed bugs (e.g. trivial null ptr accesses went unnoticed),
raised issues, and tried to add missing functionality such as update
hooks. It's unclear if the rust-bindings are a priority or covered by
the principles laid out in the libsql manifesto. From the outside it
looks like focus has shifted to https://github.com/penberg/limbo.
* As for the C-libsql fork for SQLite itself, it's getting more and
more outdated (2024-01-30 (3.45.1)) and it's unclear when and if the
ideas from the manifesto will manifest.
Looking forward this opens the door for TrailBase to:
* Bundle more recent versions of SQLite
* Implement more performant, better scaling execution models.
* Implement realtime APIs for subscribing to data changes.
After spending too much time researching licenses, my laymen
understanding makes me feel that OSL-3.0 will be a better match given
TrailBase's rare dual use as a standalone backend or framework.
It tried to outline the reasoning in the README.md. I would appreciate
input from anyone more experienced with licenses.
For now, I would like to turn my attention back to more technical issues
:hide:.
