[bind10-dev] config experiment

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

i've just committed a little experiment for the configuration backend, it's in
experiments/jelte-configuration/

There are quite some open issues (including whether this is even the correct way
to approach it), but let me elaborate on it a bit first.

Since we want to have a heavily modular system, and apart from 'have the
features from bind9' we don't really know what types of configuration future
components will need, i've been trying to make something that is as flexible as
possible. To achieve this, i've for now opted to make something that does not
really have any knowledge about what data it is storing, in essence it is just a
tree, where leaf nodes contain one specific option, and branches represent
grouped options.

The idea is more or less based on gconf and the firefox configuration service;
if allowed (although there's no checks for permission yet), you can add any
branch/name/value you want. The idea is that the components contain the
knowledge about what data there is, and how that data is structured.

One possible representation then is this:

auth/options/listen-on              integer     53
auth/options/version                string      bind10
auth/options/hostname               string      localhost
etc.

Here we have a branch 'auth', which contains one branch 'options', which
contains 3 entries.

This does bring quite a big piece of inconvenience for some things; a list of
data where elements have their own branches can only really be represented as a
collection of branches where each branch is one element.

(zones for instance, which are now done thus:
auth/zones/tjeb.nl/type             string      master
auth/zones/tjeb.nl/file             string      /var/bind10/zones/tjeb.nl
auth/zones/shane.com/type           string      slave
auth/zones/shane.com/masters        string      [192.168.8.10, 192.168.8.11]
)

(that last one could actually perhaps be done with a basic list type, but i've
only included the basic types integer, string and boolean so far)

As a module, you can add two types of callbacks on data entries; there is a list
of can_change() callbacks and a list of on_change() callbacks in the ConfigEntry
(and the plan is to also have these for (sub)trees). If setXValue is called, all
 registered can_change() functions are called, and if one of them returns false,
the value is not updated (yes, this could use a more elaborate feedback
mechanism than simple true/false). If a value is succesfully changed, all
registered on_change() functions are called with the new entry.

I've created a little tool to play with it (./example); it reads a set of
configuration data from example.conf, or if that file does not exist from
example.defaults. You cannot add data within this tool, but you can play around
with it a bit (type in 'help for some instructions'). On quit, it'll save the
data to example.conf.

There are still quite some open issues, how to do integrity and transactions,
defaults, and constraints. And of course how to fit all types of config data
into this structure. I have some ideas for most of these, but it might be time
for a bit of discussion about the direction in general, and the stuff so far
first :)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqfxJwACgkQ4nZCKsdOncVU3QCeNLLjaJil2IuJZK9ft4L7UlWb
ArIAnR2dQoRCBY94zGYYF5JQ06V75jMt
=GC0n
-----END PGP SIGNATURE-----