linux registry (no, not that again!)

markw at mohawksoft.com markw at mohawksoft.com
Wed Jul 28 18:44:03 UTC 2004


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.
There will be demands for greater levels of hierachy, more flexable data
handling and binary data. As more Windows developers jump ship and come to
Linux, we old time UNIX geeks will be surrounded with windows developers
adding bad things to Linux, not out of mallice, but out of habit.

The need for a standardized configuration API is real. The requirement
that it be optional is absolute. The desire for it to default to plain
text files is important. The ability to change the data storage
methodology is fundimental.

The questions are:
(1) How does this get implemented and propagated to the various projects?
(2) How is it "contained" such that a Windows-like registry does not creep
into Linux?
(3) How do we provide for multiple storage handlers for cases like shared
configuration?
(4) How do we make sure that a specific storage handler does not get
"defacto" mandated by a too popular program?


In reallity, this is a very simple API library. The fact that there is no
standard implies that it is a very hot potato and it is unlikely that it
will get adopted.







More information about the fedora-devel-list mailing list