2026/02/08

Sunday, February 8, 2026 (#39)

Saturday Sunday Monday posts: prev < this > next

...and now we run into the architectural problem created by the fact that we're using a completely different command (mysqldump) for exporting than for anything else.

Two obvious solution-paths:

1. Re-implement mysqldump as SQL commands, so we can use the usual mariadb/mysql wrapping.

2. Engineer up some way to allow for nonstandard CLI commands in the Engine Server clade.

I'm very much more inclined towards #2, since it might be tricky to work out exactly what mysqldump does. (It may or may not be fully documented, and compatibility-essential details may or may not be subject to change. It already seems likely that there's some incompatibility between how MariaDB and MySQL dumps work, so we'd need to re-implement each of those individually.)

I'm seeing two possible ways of implementing that:

2a. Add a feature to CmdLine which can instruct the Engine Server to use an alternative command/mode.

2b. Allow the Engine Client to talk directly to the Engine Server, and tell it directly to use an alternative command/mode.

Option 2a breaks the architecture the least, so I'm leaning towards something like that but which could make sense in a larger context.

Ideally, the mode-feature would make no assumptions about the recipient of the mode-change or the nature of the mode being requested. Any mode-hint would be attached to some kind of semantic indicator (e.g. "engine"), and each step along the cable-chain would look for any hints addressed to it. That would allow us to generalize the mode-feature to work with other pieces of the chain -- e.g. tell ssh whether to use nonblocking/buffered mode or just wait for all the output.

This seems to be working out well. The next challenge is how exactly to convey the output file (stream) from one end of the chain to the other...