Currently has method and database linked. And as illustrated by JDBC, method can have more than one level, e.g. a subprocess connection to JDBC to then a database.

Ah, we're going to need "generic-database" as a database type to provide minimal functionality for databases supported by e.g. JDBC for which no one has written a specific adapter.

My intuition says method shouldn't have any user callable procedures, its configuration information and tuning during runtime if needed can be passed down and through sdbi and connector, how you get to a database should be effectively invisible. Whereas a particular database will likely have special features specific to it that won't fit into the normal model of the API. And this fits with the decision to not try to make switching databases transparent, it's query language agnostic in part because experience has shown DSLs have severe limits with SQL.

So I'm proposing to make it the connector's job on any given Scheme implementation to create the correct stack below it. So you'll import something like (sdbi) and (sdbi connector mariadb), connector again mostly being there for carving out a large portion of the sdbi library namespace.

This also allows for (sdbi connector jdbc), if that interface turns out to have some specific needs that aren't well satisfied by sending a-lists down from the sdbi level.

Or there will be a configuration procedure to call first. db-alist == the database's "connection string". stack-alist tells connector to set up a stack of e.g. ffi sqlite3, or subprocess jdbc generic-database.