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