Hi Ken,
True, but `it's POSIX' and that was used for iconv to make it
mandatory. And optional means the code and the tests have to be
that bit more complex.
If this was used in more than one tiny location, I'd find this
compelling. But it's not quite the same as our use of iconv(), which
happens in a bunch of places and can be legitimately be argued as core
functionality.
Well, caches to speed up other things have been mooted from time to
time, but POSIX's ndbm.h isn't up to supporting them as a strictly
POSIX-conforming program is crippled by how it can use a ndbm.h
key-value store.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dbm_store.html
explains the limitations, e.g. all keys that hash the same, and their
values, have to fit in a block, the hash can't be obtained, the error
when the block's full is no different to an error for another reason.
By all means make ndbm.h optional, it's pretty useless for a conforming
program, but at the moment it doesn't seem to be causing ./configure
trouble to porters.
BTW, I see nmh's DBM can be manipulated from the shell for those wanting
to poke or prune.
$ gdbmtool test/testdir/Mail/maildelivery.pag
gdbmtool> first
2@test.nmh\000
Fri, 02 Feb 2018 11:48:29 +0000\n\000
SQLite would be another way, I think Lyndon used to suggest it? But
it's a lot bigger, not POSIX, and we'd be writing SQL. OT: The Fossil
SCM is used to develop SQLite and uses it as the centre of its storage,
but then they're masters at it and its application. It gives then ACID
`for free'.
The current implementation of Fossil stores each artifact as a BLOB
in an SQLite database. The current implementation also parses up
each control artifact as it arrives and stores the information
discovered from that parse in various other SQLite tables to
facilitate rapid generation of reports such as timelines, file
histories, file lists, branch lists, and so forth. Note that all of
this additional information is derived from the artifacts. The
artifacts are canonical. The relational tables serve only as a
cache.
— https://www.fossil-scm.org/index.html/doc/trunk/www/theory1.wiki
Berkeley DB used to be an easy recommendation, but it's now Oracle's,
not Sleepycat's. There's a host of key-value C libraries now, e.g.
https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database that came
about to improve on Berkeley DB in the common `append' case.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers