BerkeleyDB and config files

[Jeff Spaleta]

On Thu, 14 Oct 2004 22:12:51 -0700, Michael A. Peters <mpeters at mac.com> wrote:
> That made it a nightmare to maintain the administration utility.
> With a database, it is much easier. The value for the setting is
> requested from the database, or inserted into the database. It greatly
> simplifies how configuration information is stored and retrieved.

Specifically... Berkeley DB is an absolutely horrible idea if you need
to have multiple people changing multiple settings involving multiple
aspects of the system. Can Berkeley DB allow for multiple writes at
the same time? There is a price to be paid for centralization into a
single embedded database. I'm not extremely keen on the idea of
implementing a centralized embedded database for all the system
configs from networking to security policy on a system where there are
more than one administrator. And since I sort of get the feeling a lot
of RHEL deployments are large network, multiple adminstrator sorts of
things, I sort of doubt its in the best interest to steer development
into the berkeley db direction.   And I'm not particularly keen on the
idea of requiring moving to heavier multiple user database like
postgres to get around the problem of single client writing locks that
an embedded database would have. I honestly don't see any gain here at
all by over-centralization of disperate subsystem configfiles inside a
database. Optional database usage, sure. Requirement, no.

> I know people are put off by this because of what MS did with the
> registry. But that was MS. Gnome does exactly this - a database for
> gnome application settings, gconf - and it works extremely well, and is
> a hell of a lot nicer than config files.

Cough... i think you misunderstand what Gconf is...and i think you'll
find a lively discussion if you care to look about the problems Gconf
has had. And frankly I wouldn't be all too shocked if Gconf gets
replaced with another attempt at this sort of thing anyways:
http://freedesktop.org/Standards/config-spec

GConf is NOT an embedded database. Its layer that sits between
applications and what could be a number of different configuration
storage backends. The commonly used backend isn't a 'database', its a
set of xml files. If GConf is the example of the better way to
approach the problem, then its not an example supports the argument
that you NEED a database backend like db4 at all.

You might be able to make a case for structured files like xml instead
of flat files, but the case specifically for a centralized berkeley db
falls short of the level of discussion thats going to be needed for
serious interest compared to previous long thread discussions
concerning 'registry' like behavior in the last 6 months. I personally
like the discussion pointing to the creation of libconfig that
implements an api for the sysconfig flat files instead of more
cumbersome solutions like a centralized db as a fedora/redhat
sysconfig specific stop gap measure before an appropriate api for
config files can be agreed on widely. But even then we get into
tradeoffs of how to build files that can be reasonably accessed with
and without advanced tools. Don't underestimate the power and
flexibility of being able to quickly open up a configuration file in
vi from a simplistic rescue environment and be able to get something
fixed, in your quest to build a file syntax and layout that is is to
build graphical tools on. There are tradeoffs invovled, and I'm not
even sure the benefits of even something simple like xml like
structured files strikes a balance to the ease of parsing the flat
files in vi when its needed.   I encourage you to look back to at
least July in the archives of this list and read up on similar
discussions.

-jef