> That is not at all clear to me.  As I pointed out, both designs involve
> three processes: the client, the server, and an intermediate program
> involving Java.

I expect the solution without MariaDB will be much lighter. DB engines
are quite big pieces of software and non-trivial to install.

> The bespoke solution requires designing (or stealing) a SQL protocol for
> the client-to-intermediate connection  If it isn't either the Postgres or
> Widenius wire protocol, it will also require a client in portable Scheme.

The subprocess protocol has to be designed anyway. And it's already
running in Scheme and Common Lisp! I'll be trivial to do in Python and
Java too. If we pick ASN.1 for the core binary format, we can change it
to use that instead of varints. This is not a substantial problem.

> Finally, a substantial intermediate program in Kawa must be written and
> possibly maintained by us or our successors that speaks the SQL protocol
> and makes JDBC calls.  I've looked at sample Kawa programs with heavy JVM
> interface, and they look a lot like Java programs with Scheme syntax.  At
> install time, the user must install Kawa, our intermediate Kawa program,
> and the client library if any.

That's why I would write it in Java with no deps other than JVM. Kawa is
great but I wouldn't depend on any JVM Scheme for a simple wrapper. Java
is good enough for jobs like that.

> WIth the Connect solution, the amortized implementation effort is zero.
> The Widenius protocol already exists.  The Widenius client is already part
> of the project's primary goals.  Connect dynamically links to the system
> JVM and does everything the Kawa program would have to do.

All of that is true.

What's that libjvm thing, are they dynamically linking an entire JVM
inside the MariaDB process? What is "system JVM", do you mean the system
installation or is there some fancier facility for having a global JVM
process running nowadays?

> The user needs to install MariaDB and Connect.

And configure them. These are the big issues.

As far as I can tell, JDBC comes standard with Java. If it had to be
installed separately, that would tip the scales closer to Connect.

To some extent this whole discussion is moot :) Connect is supported by
some MariaDB client we'll end up making anyway. A JDBC suprocess is a
matter of coding one, so it's the problem of whoever will code it :)
Where's the harm if someone does the work?

> (In either case, a JVM would need to be installed if not already present.)

True.