The main thing in this release is a plugin system for database drivers. The short version: plugins are standalone executables that Tabularis spawns as child processes and talks to over JSON-RPC 2.0 on stdin/stdout.
I looked at dynamic libraries first but the cross-language ABI story is painful and would have locked plugin authors into Rust (or at least a C-compatible interface). The stdin/stdout approach means you can write a driver in whatever you want — the only contract is the JSON-RPC protocol. It also gives you process isolation for free, which matters when you're dealing with database drivers that can have their own native dependencies and failure modes.
The tradeoff is some serialization overhead per call, but in practice you're always waiting on network or disk anyway, so it hasn't been an issue.
First plugin out is DuckDB. I kept it out of core because of its binary size, but it's the database I get asked about most, so it felt like the right first target.
One thing I'm still thinking through: whether to pull the built-in drivers (MySQL, PostgreSQL, SQLite, MariaDB) out of core entirely and treat them as first-party plugins. It would make the core much leaner and the architecture more consistent, but it adds friction on first install. Currently leaning toward a setup wizard approach. Curious if anyone has dealt with a similar tradeoff.
debba•1h ago
The main thing in this release is a plugin system for database drivers. The short version: plugins are standalone executables that Tabularis spawns as child processes and talks to over JSON-RPC 2.0 on stdin/stdout.
I looked at dynamic libraries first but the cross-language ABI story is painful and would have locked plugin authors into Rust (or at least a C-compatible interface). The stdin/stdout approach means you can write a driver in whatever you want — the only contract is the JSON-RPC protocol. It also gives you process isolation for free, which matters when you're dealing with database drivers that can have their own native dependencies and failure modes.
The tradeoff is some serialization overhead per call, but in practice you're always waiting on network or disk anyway, so it hasn't been an issue.
First plugin out is DuckDB. I kept it out of core because of its binary size, but it's the database I get asked about most, so it felt like the right first target.
One thing I'm still thinking through: whether to pull the built-in drivers (MySQL, PostgreSQL, SQLite, MariaDB) out of core entirely and treat them as first-party plugins. It would make the core much leaner and the architecture more consistent, but it adds friction on first install. Currently leaning toward a setup wizard approach. Curious if anyone has dealt with a similar tradeoff.
The plugin guide and protocol spec are in the repo if you want to build one: https://github.com/debba/tabularis/blob/main/plugins/PLUGIN_...