> Harold has kindly volunteered to lead the effort to create a SRFI
> specifying a Scheme API for talking to relational-style databases.   I am
> very grateful to him for this: as chief cook and bottle-washer for the
> ongoing R7RS-large effort, I have more than enough on my plate without the
> database API too, and I was starting to feel "thin and stretched", as Bilbo
> says.  I have bee impressed with Harold's effort and dedication on the SRFI
> 170 (Posix) design and implementation, and I am confident that he can
> produce a good result that will unify this very complex and difficult
> problem.

Excellent. John, your indefatigable efforts with the larger R7RS are
much appreciated.

> By "relational-style" I mean that the query language is not limited to SQL
> or even the general family of relational algebras.  It can be anything at
> all, provided the result is organized as rows and named columns. Some graph
> query language provide this sort of output, and will be under the umbrella:
> others don't, and will require their own API.  (Perhaps "rectangular" would
> be a better word than "relational" in "RDBMS".)

Bright idea to limit the problem domain based on result shape.

> Harold tells me that he hopes to provide drivers for at least PostgreSQL,
> SQLite, and MySQL/MariaDB (the Widenius sisters), the most widely used
> open-source RDBMS engines.  He will also be taking Oracle and Microsoft SQL
> Server, the most widely used proprietary engines, into account as far as
> possible, along with whatever else makes sense.

Harold, we could decide how to split the implementation workload (of
course assisting each other as needed, but development will probably go
easier and produce better code if one person is the main developer /
code reviewer of a particular backend).

- I could finish the subprocess backends of SQLite and Postgres.

- Do you want to do C FFI backends of those databases?

- What about the JDBC subprocess backends you expressed interest in? I
looked into JDBC cursorily; comes standard with Java (no dependencies
other than JVM) and seems nice enough.

- We could also explore a Python backend, but DB support would mostly
overlap Java and C. I can't find a list of databases supported by
Python. So far the C libraries have not been hard to do; the effort went
into spending a day writing the S-expression support for C.

- I'd be happy if more people want to write backends for something;
SQLite and Postgres is enough for me :)

> I look forward to seeing what he comes up with.

John, do you still want to be actively involved with developing the
text/binary data encodings despite leaving the database stuff to Harold?