To Home page
In Microsoft Windows and in Linux, managing configuration data has grown to become a huge problem.
In Windows this is stored in the registry, which is hierarchical database. In Linux, this is stored in plain text files, which is something of a problem as it is easy for these to be incorrectly formatted. On the other hand, the Windows registry is also a problem, for it is a database that fails to scale. We need a database that can efficiently handle a hierarchical tree containing a very large number of very small flat tables - the file system already provides hierarchical trees, and Sqllite provides flat tables, so the quick and dirty way to do that is the way Linux already does it.
But both systems suffer from the big problem that any program can write to the configuration data of any other program, and no program can protect its configuration information from being changed into an inconsistent state. It is very common to make a mistake editing the configuration data, and suffer mysterious and dreadful consequences.
So each package should get its own private data spaces, in which it stores data both as plaintext, and as Sqlite databases.
We want fine grained control over access to these data spaces, so that an installed package can prevent them being changed in surprising ways or to inconsistent states.
In all cases, only package code should be able to change the data, though this may well mean that the standard configuration editing tool sends messages to package code, which package code can then act on such messages in the standard generic fashion, or ignore such messages, or reject some change messages with an error message.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License