Date: Wed, 07 Mar 2001 00:38:48 -0700 From: Wes Peters <wes@softweyr.com> To: Robert Clark <res03db2@gte.net> Cc: Terry Lambert <tlambert@primenet.com>, Matt Dillon <dillon@earth.backplane.com>, chat@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <3AA5E588.F2606C07@softweyr.com> References: <200102200122.SAA04466@usr05.primenet.com> <ybupugd2u4n.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <3A934507.A0645CF3@softweyr.com> <ybug0gr3hsc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <15012.11507.801736.502035@guru.mired.org> <3AA4A110.5245FCD4@softweyr.com> <20010306103744.D45802@darkstar.gte.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Clark wrote:
>
> Wes,
> Have you seen any intelligent discussion of
> the whole concept of whether to keep config info
> in flat files, or to use a bindery/database? (Something
> I could go read up on.)
No. We hashed this over at my work -- building a BSD-based "appliance" --
and settled on a database for other reasons. As we get herded into
smaller and smaller appliances, the database will probably migrate into
some other form of storage, but we have attempted to virtualize our
storage and retrieval of configuration information so we can move to
a different storage manager with (relatively) little pain.
We originally started with simple XML files, but they are rather difficult
to update with volatile data. XML was designed for data exchange, the
format lends itself to being read and written, but not updated. To make
an update, you end up reading and rewriting the entire contents of the
file for each update.
> I often wonder if a standardized api for
> storing and retreiving config info would be a benefit
> to *BSD.
Yes, because an API makes the storage method far less important. It
could be argued that an ODBC interface for all system configuration
information would be "the best" way, because you could implement any
ODBC back-end to store the bits somewhere.
> This whole subject seems like an unimaginably
> big can o worms.
>
> Even the staunchest advocates of the bindery/
> registry don't get it completely right. (as far as I've
> seen anyway.)
Matt Dillon has a good point that clumping different kinds of data into
one store just because they're "configuration" data is ill-conceived.
I agree, the temporal proximity in terms of when the data is accessed
in the boot process doesn't make it a good candidate being lumped
together in the same file.
Considering each piece of system configuration data as an object, reviewing
its internal and external attributes (what kind of object is it, how often
is it accessed, how often is it updated, are there other closely related
bits of information that might be attributes of the same object, etc.) is
an excellent exercise, if it yeilds some working code or design information.
From my experience, designing our configuration in terms of a relational
database was a good exercise, because it got us to think about the data
in terms of what it represents, and the relationships between the data.
Going from the design we have now, which is documented in the form of
comment SQL command files, to any other data store, would be a straight-
forward task. We might even pick up some speed along the way.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AA5E588.F2606C07>