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.
