> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, September 16, 2019 8:50 AM
>
>>>> Well, if it's a protocol, then drivers can be written in anything -
>
>> 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.
>
> Very interesting. JVM is even more heavyweight than Python, but if it
> helps you get to an exotic database why not. JVM is probably also gives
> the most identical programming environment across operating systems.

Officially it gets us a lot of databases, exotic, or not, e.g.:
https://www.oracle.com/technetwork/java/index-136695.html

> As much as I like Kawa, it may be overkill to go with any Scheme on
> the JVM. Ideally it's just a simple wrapper, which could be written
> in Java avoiding extra dependencies. Of course, a Kawa JDBC wrapper
> would be very useful for applications written in Kawa, and whoever
> writes the wrapper chooses their tools :)

Well, if a Java programmer wants to contribute....  If it's me, it'll
be Kawa (or Clojure).

>>> this approach is more for situations where an implementation
>>> doesn't have a FFI
>>
>> And doesn't implement TCP/IP, since aside from SQLite, how many of
>> these databases lack a documented TCP/IP wire protocol?
>
> No idea but:
>
> 1) I wouldn't be surprised if commercial databases lack open protocols.

Neither would I.  Worse, it's occurred to me that there's possibly
more churn with over the wire protocols than vendor supplied libraries
that use them.

On the other hand, how many Scheme implementations don't support TCP/IP?
Your pipes to a subprocess concept has great merit for such, even if a
subprocess facility has to be added, I suspect.

> [...]
>
> Blowups of various kinds can be expected in any complex database work.
> Just wait until we get to non-ASCII text in big production databases..

Yeah, that's going to be immense fun....

My current thought is that the obvious 2 layer approach for plumbing
should be used.  To borrow the influential Perl library nomenclature,
a DBI database interface that user programmers directly interact with,
which I hope can be query language and data type agnostic/ignorant,
and below that DBD database drivers that know their particular
database, and have the job of converting Scheme data types to and
from the database's.

- Harold