> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, September 16, 2019 4:22 AM

>> Well, if it's a protocol, then drivers can be written in anything -
>> I suspect the point was that lots of databases have C client
>> libraries, so writing a protocol driver around them in C would be
>> the easiest option.
>
> Exactly :)

Perhaps it would be easier to mix this with my current impression that
the highest payoff in support of "second class" databases (i.e. those
other than MySQL, PostgreSQL, and SQLite) might be through JDBC.  In
that case, the subprocess would be a JVM, and it would be natural to
write a great deal of its code in Kawa, instead of something alien and
compared to what you can do with a JVM, less performant than Python.

For SQLite we probably ought to eventually write or adapt an existing
C server, after we figure out how to do this (mostly) with Scheme.
Perhaps after writing a server based on a lightweight Scheme with a
friendly FFI facility.

>> But: I suspect this is a distraction. Linking to C libraries
>> in-process versus writing a C wrapper that we talk to in a separate
>> process is perhaps more about how an FFI to C is implemented, than
>> inherent to the design of a database interface...

> Indeed, this approach is more for situations where an implementation
> doesn't have a FFI or you don't want to use it. I propose it as a
> complementary approach to FFI wrappers, not as a replacement.

And doesn't implement TCP/IP, since aside from SQLite, how many of
these databases lack a documented TCP/IP wire protocol?

> To the Scheme application programmer, it would be best if any
> subprocess approach offers an identical (or nearly identical)
> interface to an FFI-based approach. It would just be an
> implementation detail. Ideally the Scheme interface would be
> specified so that it supports both implementation styles (or mixing
> and matching them for different databases, depending on what happens
> to be available or expedient on the host system). We could start
> implementations using both approaches early to make sure the spec
> takes all scenarios into account.

Exactly, for us an implementation detail which we make sure we get
right by parallel development, for a user just a different way to
set up their stack, and at the Scheme API level a different
configuration handed to the [whatever]-connect procedure, and whatever
leaks out of the abstraction like a Java backtrace on a blowup.

- Harold