Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.

[Ralph Corderoy]

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
    address@hidden
    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