scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 18:30 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela 10 Jul 2019 18:50 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 19:43 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error John Cowan 10 Jul 2019 19:56 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 20:05 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela 10 Jul 2019 20:32 UTC
Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 22:10 UTC
Re: Systems lie about persistence and consistency promises. A lot. John Cowan 10 Jul 2019 22:20 UTC
SQLite only SRFI? hga@xxxxxx 11 Jul 2019 01:49 UTC
Re: SQLite only SRFI? John Cowan 11 Jul 2019 03:22 UTC
Re: SQLite only SRFI? hga@xxxxxx 11 Jul 2019 08:19 UTC
Re: SQLite only SRFI? John Cowan 11 Jul 2019 13:32 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:26 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:42 UTC
Re: Systems lie about persistence and consistency promises. A lot. John Cowan 10 Jul 2019 22:49 UTC
Re: Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 23:01 UTC
Re: Systems lie about persistence and consistency promises. A lot. Arthur A. Gleckler 10 Jul 2019 22:51 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:59 UTC
Re: Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 23:19 UTC
Schemepersist, anyone? hga@xxxxxx 10 Jul 2019 23:40 UTC

Schemepersist, anyone? hga@xxxxxx 10 Jul 2019 23:40 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, July 10, 2019 5:26 PM

> > [...]

> > Potentially develop a *Persistence* Manager SRFI that breaks
> > absolutely no ground in low level implementation details, concept,
> > and primitives and code we ... borrow from the best.  But is easy
> > to grok and use.

Already renamed it to sound less imposing.  And instead of a RDBMS
mailing list/de facto working group at the level of Schemedoc and
Schemeweb, we could create a Schemepersist one, covering the current
OKVS work (SRFIs 167-8), RDBMSes, this persistence manager concept,
whatever less ambitious things we might try in fsync land, etc.

> This sounds a bit like "fast, safe, easy - pick any two". But major
> bragging rights to anyone who manages to pull it off for any scenario.

Heh.  But the idea is to provide a nice and well documented interface
to existing good things while inventing absolutely nothing underneath
it so the users can pick the trade-offs they need.

> > This has been a interest of mine since I was given a job to make a
> > custom database that just stored data reliable; I'll put it on my
> > long term TODO list, during/after tackling the SQL RDBMS issue.

> Not the easiest job in the world for one person (or even a team!)

Indeed.  Which means ruthlessly limiting the scope; I would say to a
single system, but that doesn't eliminate partition problems.

- Harold