debba

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_...

I’m working on tabularis, a lightweight desktop database management tool designed for developers. It provides a modern interface for managing MySQL/MariaDB, PostgreSQL, and SQLite databases through a native desktop application. Built using Tauri v2 (Rust backend) and React 19 (TypeScript frontend), it offers native performance while maintaining the flexibility of web technologies.

Since Storytel doesn't have an official desktop application, I developed one using Electron to fill that gap.

The app provides a native desktop experience for listening to audiobooks and reading ebooks from Storytel on your computer.

Key features:

    Native desktop application for Windows, macOS, and Linux

    Can also be used as a web app

    Built with Electron for cross-platform compatibility

Recording phase: All terminal output including ANSI escape codes, color sequences, and cursor movements are captured exactly as they appear - no processing or stripping occurs.

Replay phase: - Decodes various escape formats (\u001b, \033, \x1b) back to actual escape characters - Filters out problematic terminal query sequences that could cause artifacts - Preserves visual escape sequences (colors, cursor positioning) for faithful reproduction

So yes, escape sequences are recorded verbatim, but the replayer ntelligently processes them to recreate the original terminal experience while avoiding terminal corruption.

I built rewindtty, a small tool in C that lets you record a terminal session and later replay it, using a simple JSON log format that includes:

- timestamp - command (user input) - output (stdout) - stderr

It works like this:

- rewindtty record session.json # Runs a shell, records the session - rewindtty replay session.json # Replays it step by step

Under the hood:

- Uses fork() to manage the pseudo-terminal - Captures stdout/stderr with timestamps - Stores everything in structured JSON for easy analysis, replay or transformation

Why I made this: I wanted a minimal tool to track terminal interactions — for debugging, documentation, and reproducibility — without relying on heavier tools or external formats.

It’s still early, but the core works and I’d love feedback or suggestions.

GitHub: https://github.com/debba/rewindtty