On Wed, 2004-07-28 at 19:44, markw(a)mohawksoft.com wrote:
After lurking for some time, I have heard the call for some
"registry-esque" facility in Linux for some time. I think there is an
important distiction to be drawn very carefully, and it falls within the
UNIX ideals.
An API need not and should not imply the format of the data being
modified. The API should be defined by "need," and the data storage should
be designed to to (1) handle the API and (2) satisfy external requirements
like text files, "/etc" default, subdirectories, etc.
For the API, a simple NAME=VALUE paring is not good enough. As was pointed
out by a previous post, Windows had a Private Profile API. When combined
with a file name and a title heading should be good enough for most all
configurations. Over time, I can easily see it gaining popularity.
Like the Windows Registry, I can see this growing into a horrible monster.
^^Only
is people are daft enough to try and treat it as a binary
container. If the program needs binary data then stick it in ... wait
for it ... another file ! If the file gets to big - then more files, if
the data has a relationship then use directories and files. If it has
records, relationships and queries then its database problem, not a
simple configuration problem.
You probably think i'm being a bit simple at this point, but why have a
full API for configuration if all thats missing an API for writing and
reading text, not a database engine - not even some clever API with
switchable back ends - just functions for text.
You are not going to get people to agree on a common standard for
configuration, most projects have drifted towards Variable=value pairs
or XML. If the application is using XML then it probably already has a
library for driving it - and is also using it for more than simple
configuration.
Before anyone suggests it - Perl is ok, but do you want it as a core
dependency for everything.
Jon