(From the SRFI-170 mailing list before Schemepersist was created.)

Subject: Re: Current status of my work on SRFI-170 and my Chibi Scheme implementation

Date: Monday, September 09, 2019 11:16 AM

First up for myself is a SRFI to specify a general interface to existing persistence engines, probably relational, at roughly the level of for example Java Database Connectivity (JDBC). It would not attempt any generalizing of SQL language specifics, but might add connection pooling to its remit.

What do you expect its dependencies to be, or will it have native (FFI and/or TCP plugins) for the actual databases?

That boils down to a fundamental scope issue, do we aim it at supporting greenfields projects, in which case we could possibly limit it to PostgreSQL and SQLite, or do we also want to support interfacing to existing databases in brownfields projects? And if the latter, how widely?

In both cases, do we want to limit this to relational databases, for which I'm thinking "yes". This we should nail down ASAP, as well as the name. For which I've been thinking sdbi if general, or srdbi if limited to relational databases. There are collisions with existing database things for sdbc and srdbc.

In either case, I was planning on native "FFI *and* TCP/IP plugins" for SQLite and PostgreSQl, which will have first class status. For SQLite with a single user there's two advantages in supporting a TCP/IP connection scheme, bugs in your Scheme implementation will have less ability to corrupt your database, and of course the Scheme implementation wouldn't require its own special FFI connector (there are of course many disadvantages like speed and complexity, but it should be an option). That said, there's no TCP/IP Scheme standards I could find just now, but the basic paradigm of using it is pretty well established.