From: "Arthur A. Gleckler" <xxxxxx@speechcode.com>
Date: Monday, September 09, 2019 10:13 AM
[...]
While I've got your and John's attention, I'm next planning on working on RDBMS interfaces and libraries, and I think a "Schemepersist" or the like @
srfi.schemers.org mailing list would be useful. There's been quite a bit of often general persistence discussion in the OKVS mailing lists, SRFI-170, and I'm sure elsewhere, and there are a variety of things to hash out before I and perhaps John can propose at least two SRFIs. No immediate need to display its existence on any web page.
I'm happy to create a Schemepersist list. I don't want to wait to announce it, though.
I just mentioned that in case updating the website was work you didn't have much time to spare for right now.
SRFI is all about bringing people together to discuss new ideas for Scheme. I would add it to the SRFI home page next to Schemedoc and Schemeweb, then announce it on srfi-announce. Just let me know when you're ready and I'll do it.
It's indeed envisioned and named in the pattern of Schemedoc and Schemeweb, and ideally supporting both those efforts since they by definition require persistent storage. I'm ready right now, just composed an initial email to it, which I suppose you might want to put a (possibly modified) copy of in your announcement so people will have a starting place without having to hunt in the archives:
[begin]
I asked Arthur to create this Schemepersist mailing list in the spirit of Schemedoc and Schemeweb, as a place to discuss general issues of persistent storage for Scheme implementations, much of which is already being spread out in various relevant SRFI lists and Schemedoc and Schemeweb. Its remit would include discussion of potential future SRFIs to draft, libraries existing, new, or improved, interface protocols we might want to support, how little we can trust today's software and hardware stacks, etc. etc.
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.
It should for example provide what's needed by John Cowan's in process SQLite focused "SRFI to provide a basic relational table capability to Scheme programs":
https://srfi-email.schemers.org/srfi-170/msg/12127109/ To make it sane and to the point, to be generally useful, it'll need two or more libraries that it can support on top of it.
Thanks for joining and contributing to the discussion!
[end]
Thanks!
- Harold