Email list hosting service & mailing list manager

Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki (05 Aug 2019 15:37 UTC)
Re: Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki (12 Aug 2019 10:40 UTC)

Proposal to add validation to srfi-167 and srfi-168 Amirouche Boubekki 05 Aug 2019 15:37 UTC

I had an idea inspired from past discussions about the subject of
getting together some infrastructure to allow to validate the data
that is written to the database.

This work with the notion of hooks [0] which are list of procedure
that are executed one after the other at some point.

[0] https://www.gnu.org/software/guile/manual/html_node/Hooks.html

The idea is to add hooks to every procedure that modify the database,
at the low level of the okvs and at higher levels like nstore-add! and
nstore-delete!

Moreover there would be hooks a just after the transaction is started
and just before the transaction will be committed, so that the hooks
can initialize the transaction-state and then at commit time proceed
to validate the state of the database based on the changes. In the
case where the validation fails it will be possible for the hooked
procedure to raise something to notify the user that validation
failed.

This allows would allow to:

- Validate changes as then happen (nstore-add!, nstore-delete!,
okvs-set! or okvs-delete!)
- Validate changes at the level they happen nstore-add! and
nstore-delete! vs. okvs-set! and okvs-delete!
- Do whole transaction validation using the precommit and transaction
begin hooks

John told me that hooks are an application SRFI 117 (list queues) and
that run-hooks might look something like:

(define (run-hook hook . args) (for-each (lambda (x) (apply x args))
(list-queue-list hook)))

I do not assume that this will make sense to everyone right now. I
will update the specification to reflect those ideas in the next few
days / weeks.

By the way, those hooks could support cascade delete and other things like that.