Accelerate by years part IV - The prototype
This is part 4 of a 4-part series of memos that propose steps to accelerate lix and inlang by multiple years.
Context
The previous post concluded that we have a once-in-a-product-lifetime acceleration possibility to accelerate both inlang and lix. Lix v1 requirements are reduced to a) a merge() function and b) and plugin API to track changes.
If we can fulfill both requirements with SQLite as the database, we will save months/years working:
Query API out of the box
Storage layer out of the box
“Subrepos” out of the box
Filesystem out of the box
Research question
Will building inlang and lix on SQLite within the next 9 months get us faster to…?
Inlang SDK features
Change history in inlang
Generalizable change control via lix plugin API
Third-party lix developers
Outcome
Watch the loom https://www.loom.com/share/cd278986484c44879857d70fc46e796
No-brainer to build lix on SQLite and say farewell to git. We are going to have lix 1.0 within the next 4 weeks. Lix boils down to plugins that diff and lix storing changes based on diffs in SQLite. Trivial. Really trivial. Apps can directly query via SQL and build UIs around change control. LOOM
Source code https://github.com/opral/sqlite-prototype
Next steps
[ ] csv merge UI with no history. i can do that.
[ ] csv merge based on history
[ ] inlang plugin