On Wed, 2004-07-28 at 19:44, markw@xxxxxxxxxxxxxx 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
