> a pure Java to JDBC connection has the least moving parts,
> and I want to quasi-directly see its API.

Agreed. My experience has generally been that the less dependencies you
have, the easier things are for users. The solution is usually more
portable, runs faster and is easier to extend. It does require some
up-front pain but the long-term pain is generally less.

> Another question is subprocess and/or wire (net) protocol, I'll leave
> that to you.  I already have one net connector with PostgreSQL, so
> my gaining experience sooner with your subprocess method would be good.

Let's use the core binary format that this project is crafting, whether
it's an ASN.1 subset or a varint based thing. I see no reason for the
extra hazards of text since it's machine-to-machine communication, and
using a tailor-made format instead of a generic one would soon paint us
into a corner when it's time to make extensions and improve tooling.

Apart from the encoding though, we could work together to evolve the
vocabulary (i.e. which messages are sent). The encoding and the vocab
are completely decoupled from each other, so they can evolve
independently. My idea for the vocab is to track your Scheme API as it
evolves, diverging as little as possible :)