Which is currently defined as an user API, architecture and APIs under that, and implementations potentially for any database with a text query language that returns rectangular results.

At the highest level, following the pattern of Perl, it will consist of a query language agnostic database interface, the DBI, and database drivers, DBDs, that provide connectivity to particular databases like SQLite3, and the specialized to databases data type conversion facilities needed to round trip data to and from Scheme.  There will be some more named moving parts, like a plugin facility for connection pooling, and round trip common type conversion libraries.


Common Resources:

All discussions will be held on srfi.schemers.org mailing lists, initially this Schemepersist one, eventually also SRFI ones.

For community locations to memorialize Schemepersist stuff:

Having witnessed the utility of a central location to place artifacts in the GitHub PDP-10 organization (https://github.com/orgs/PDP-10/dashboard), I've created one for Schemepersist in general at https://github.com/Schemepersist.  Contact Lassi (has more experience with GitHub organizations, is 8 times zones ahead) or myself (focused on Schemepersist, is 8 timezones later, US Central Time) for anything administrative needed for it.  Note that if you want to transfer a repository to it, you must specify the organization in lowercase, "schemepersist".

I've also bought schemepersist.net as a place to put minimal amounts of text, and a lot of links, to everything relevant to the Schemepersist effort, our work products and others'.  (A .net because .org domains are facing uncertain pricing with the removal of price caps in the new contract ICANN made with Public Interest Registry (https://icannwiki.org/Public_Interest_Registry)).


Where we are today:

John's Simple SQL as already discussed on Schemepersist is close to what I envision for the DBI user API, although we're all still thinking about statement parameters.

Lassi has been working on serialization AKA encoding and the subprocess connection method.

I've been doing a lot of research and designing, my scratchpad git repo for that is https://github.com/Schemepersist/sdbi-design.

I will immediately commence building minimal Chibi Scheme connectors to, in alphabetical order, the wide column Apache Cassandra, graph NeoJ4, and SQL RDBMS PostgreSQL and SQLite3 databases.  These four provide a good intersection of desired characteristics including popularity, with non-SQL diversity from the first two, and I'm at the point in the design process where I have a clear enough target at the top, and need to work up from the bottom to fill in some gaps in my design, and to anchor it in reality.


Short term requests:

For schemepersist.net, a nice looking theme, and Markdown to HTML static site generator recommendations.

Someone to start prototyping the JDBC connector if Lassi isn't going to do it.


Long term requests:

It would be great if others supplied a DBD for MySQL/MariaDB, which along with the other 2 major FOSS RDBMSs, PostgresSQL, and SQLite3, is slated for "first class" support.

DBDs, for SQL Server and Oracle, both of which have free to use *for production* (with limits) editions (!!).  I also saw a link to an SQL Server free full development version, and Oracle used to do that.  Warning, Oracle's license has a danger of subjecting you to an audit, and those aren't nice for companies.  I've used Oracle a lot in times past and really like the technology, and supervised a SQL Server project, but my plate is already full, and I won't be using either in Real Life in the future.

At least one Scheme implementation in addition to Chibi Scheme ought to implement the whole sdbi stack before any SRFIs are finalized.

As Lassi mentioned, one person should be in charge of every DBD; I'd like volunteers to take over any or all of the 4 I'm initially going to be focusing on.

Thanks to all, let's see if we can create some long lived first class infrastructure for the Scheme community.

- Harold