> On 9 Nov 2023, at 16:15, Greg Stein <gst...@gmail.com> wrote:
>
> Personally, I'd deprecate apr_dbm entirely, and direct all clients towards
> sqlite.
>
> The DBMs were intended for simple key/value stores 20 years ago. We have much
> better tech now. Sqlite does K/V so much better, *and* it handles
> processes/threads. I really don't see a reason for DBM nowadays.
>
> Who can justify using (say:) ldbm over sqlite?
Legacy apps? I first used ndbm more than 30 years ago. Software from
that era is still in use, and might crop up in someone's work today.
I *think* I even wrote about the apr_dbm concurrency issue long ago,
in an era when non-thread-safe libraries were being adopted willy-nilly
and to point it out was to be labelled a stick-in-the-mud enemy of progress.
+1 to deprecting apr_dbm, provided we explain exactly why (so users
are clear whether or not it matters to their use cases). The alternative would
be smart locking code within apr_dbm, and I doubt that anyone wants to
put that effort in.
Applications can still use a dbm of their choice without the APR layer.
--
Nick Kew
