From: John Cowan <xxxxxx@ccil.org>
Date: Friday, September 20, 2019 9:28 AM
I'm more than a bit hesitant to declare that my entirely theoretical API will become official. And I doubt John would be willing to wait for perhaps a year for it to possibly become a real thing and even an SRFI, while the Scheme community needs yesterday a persistence facility ably supplied by the zero-admin dynamically typed SQLite.
I'm not fussed about that . There are already implementation-specific libraries.
Let's focus on getting the client API and the subprocess protocol right. Then a Scheme library that talks to a subprocess (hopefully using S-expressions or ASN.1 rather than a bespoke serialization) that speaks the SQLite API will be both portable and usable, and will get the SRFI finalized. A second implementation will be a Good Thing for standardization, and of course many more can follow.
I *really* doubt our APIs will be compatible. We're coming at this general issue of persistence from completely different directions to solve nearly completely different problems supporting nearly completely different use cases, as your continued primary focus on SQLite above emphasizes.
It's clear our tastes in critical API details differ, and it'll also take me at least a month or two for enough prototyping with Cassandra, Neo4j (and learning the tiniest bit about their wide column and graph paradigms), SQLite, and PostgreSQL to answer many of my own outstanding questions, as well as ones for a potential common user level API. Data transformations, how to specify and implement are a big issue, I think a much bigger issue for me when SQLite only has NULL, INTEGER, REAL (floating point), TEXT, and BLOB, and doesn't enforce them at all (modulo TEXT having a ~2,000 character limit??).
TL;DR I have serious doubts about our trying to force a common user level API as a standard. It risks generating friction fatal to my effort.
- Harold