[bind10-dev] config experiment 2
Jelte Jansen
jelte at isc.org
Sun Sep 20 19:52:10 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
after the phonecall on thursday I've been working on a new configuration manager
experiment. It is far from finished, but since I'm leaving tomorrow and don't
think i'll be near any computer for at least the next 10 days, i thought i'd
commit what i have so far so people can take a look at it and hopefully be a bit
less blocked :)
I've moved the old stuff to experiments/jelte-configuration/old and put this in
experiments/jelte-configuration itself. Changes and additions can be safely
committed if you like.
I haven't seen the communication stuff yet so that's a big part that is missing,
but what i have so far is this;
config_obj.[cchh] is the main object for configuration; this is supposed to be
used by the modules, manager, and user interface tool, and contains
configuration data. It is an API around the specific xml structures (in this
case i've chosen for Xerces, it's apache-licensed and widely available, but if
anyone knows a better one it's not too hard to replace, all functionality we
need for now is wrapped in config_obj.*). It is a wrapper around (a part of) the
configuration. Please take a look at the header file, i've included all
modification functions that seemed useful for now, but i'm sure i've missed a
few things.
The usage model is that through the communication system a blob of xml is
passed, which is parsed by the Config object constructor and put into the
object. The client then modifies it and sends it back. On the manager side this
would be implemented by getConfigPart() and setConfigPart(). The manager should
then check the values, update it, and notify registered modules. Though no
checking is done at the moment (none at all, you can pass it anything as long as
it looks like valid XML), and no notifies are sent yet.
The config_manager right now has some comments about where it would do these
things, but at the moment is contains in it's run() method merely a set of
example functions that get and set a few values.
Currently on startup it reads the local file myconf.conf, which eventually could
be replaced by another data store. On succesful exit, it now writes to
myconf_new.conf to show the differences.
Since xerces has no XPath support, and having that would require yet another
library, i've added a string-based selection/addressing system that looks a bit
like it, which should be enough for now, i think (it's described at the top if
config_obj.hh). We could easily decide to put in full XPath or another
addressing system.
My version of xerces also has no serialization support (i think that's in
version 3+), so i've added a really simple serializer as well. Again, shouldn't
be hard to replace later.
As said, it does virtually no checking. We could add a DTD to the parser, so at
least the model is verified, but i haven't done that yet.
Anyhew, i hope it's useful for now, please take a look at it, and i will see you
guys in about two weeks.
Cheers,
Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkq2h+gACgkQ4nZCKsdOncUG7wCgt2uuvhB+fHqd9qdkvAObbEnk
dKwAnjDosJKGpe6GJz4VAdlOHZPcaM60
=P67j
-----END PGP SIGNATURE-----
More information about the bind10-dev
mailing list