> Thanks, but it's not quite to that point, there's still a lot of Sidney
> Harris "THEN A MIRACLE OCCURS" steps to be more explicit about ^_^.
> That said, my design intuition is pretty good by now.

I also feel quite confident that  we have explored the problem space
well. As for subsuming rectangular results from non-SQL databases, one
can never be fully prepared for that kind of thing :)

> This is a very good point.  To use the current (iffy) hierarchy of sdbi
> for this, I have, for example, running in bare direct prototype form:
>
> (sdbi connector ffi sqlite3)
>
> And:
>
> (sdbi connector net postgresql)
>
> To which Lassi is proposing to add something like:
>
> (sdbi connector subprocess-jdbc)
>
> Which would be used as:
>
> (sdbi connector subprocess-jdbc [obscure database])

The ffi/net/subprocess hierarchy is very nice!

I thought it'd be just (sdbi connector subprocess). The JDBC subprocess
would speak the same generic protocol as all other subprocesses, and the
specific database to which JDBC should connect can be given parameters
in the "connection string" when opening the connection. At least it's
been my impression of JDBC that it's generic enough that this kind of
thing would work :)

> Perforce, there will be a generic protocol between the connector layer
> and the one below it, although in John's favor I need to look at the
> PostgrSQL and Widenius wire protocols for ideas.

If I have understood JDBC correctly, it can use the generic subprocess
protocol with no changes.

> The latter ... however
> much it'll gain us with CONNECT, as far as I know it needs a champion to
> be implemented any time soon.

If I understood John's description correctly, CONNECT can use the
ordinary Widenius socket protocol with no changes.

> As for CONNECT (https://mariadb.com/kb/en/library/connect/), does it
> represent a single point of project institutional failure like I
> perceived SQLite3 to be?

Probably :) Here too I'd say the main point is to design the Scheme side
of the database framework so that any net/ffi/subprocess is easy to add.
Then if CONNECT turns out to be dodgy we can implement another route.

> I again ask this to determine how much sdbi should be influenced by
> a potential mayfly.  In the meanwhile I'm mining it for ideas.

Again if I understood John correctly, CONNECT takes normal SQL queries
and returns normal SQL results, as does JDBC, so in all respects (except
some funny connection parameters / proprietary SQL statements) they
should work like a normal database.