I am happy to announce the first release of "Hiveconf", a UNIX configuration framework. Hiveconf is a system for storing configuration data (key-value pairs). The purpose is similiar to the Windows registry or GConf. Configuration data can be retrieved and modifyed via a simple API. The data is stored using different "backends". The default backend is using a text file format, similiar to smb.conf or Windows .INI files.
This first release includes a Python library implementation, and documentation of how the system is intended to work. Lot of work remains to be done, but the current implementation is mature enough to demonstrate the basic principles.
The implementation also includes a command-line tool ("hivetool"), which might be a useful tool for configuring any software that uses a Hiveconf compatible file format. This includes Samba and many KDE applications.
On the Hiveconf homepage, http://www.lysator.liu.se/~astrand/projects/hiveconf/, you will find links to the mailing list, CVS repository etc.
Comments are appreciated.
Congratulations. This looks pretty cool. Running code! I've linked it into my unix config page.
I have some quick comments.
* your overview could be improved by describing how hiveconf is different from gconf and the windows registry (and for that matter linuxconf, webmin, dotfile, etc.)
* I think samba is a great place to start. Presumably you could at some point make up an unofficial patch which implements hiveconf as an option for samba. The simplest such patch might be just a symlink from smb.conf to smb.hconf!
Samba has some things which are pretty interwoven and hairy to configure, for example guest access to printers but with security = user. It owuld be interesting to explore how metadata might be able to help novice and or expert sysadmins to navigate the samba config.
* .hconf seems a bit clumsy to me as a file extension. .hiv ? But no matter, it's your right as coder to choose such aesthetics.
* one issue that could be important early on is how a user can determine whether hiveconf config data is being used by an application. There's nothing more frustrating that configuring a file only to have an application ignore it. A GUI could display a hiveconf logo or text or something when hiveconf is activated. But a daemon or console program would need some other way. It might output hiveconf info during a --version. Or a daemon might stamp a daemonname.hiv.run file with a date when the file was last read (you don't want to change the config file itself unless actual app config changes have been made). Or hiveconf could log when a particular config file was accessed and by which process. Or something. Stuff to think about.
This last issue is presumably where hiveconf might diverge from gconf, which (from afar) seems more oriented towards GUI apps.
All the best for your project!
Cheers, Matthew.
On Mon, 23 Jun 2003, Peter Astrand wrote:
I am happy to announce the first release of "Hiveconf", a UNIX configuration framework. Hiveconf is a system for storing configuration data (key-value pairs). The purpose is similiar to the Windows registry or GConf. Configuration data can be retrieved and modifyed via a simple API. The data is stored using different "backends". The default backend is using a text file format, similiar to smb.conf or Windows .INI files.
This first release includes a Python library implementation, and documentation of how the system is intended to work. Lot of work remains to be done, but the current implementation is mature enough to demonstrate the basic principles.
The implementation also includes a command-line tool ("hivetool"), which might be a useful tool for configuring any software that uses a Hiveconf compatible file format. This includes Samba and many KDE applications.
On the Hiveconf homepage, http://www.lysator.liu.se/~astrand/projects/hiveconf/, you will find links to the mailing list, CVS repository etc.
Comments are appreciated.
-- Peter Åstrand www.thinlinc.com Cendio Systems www.cendio.se Teknikringen 3 Phone: +46-13-21 46 00 583 30 Linköping
Congratulations. This looks pretty cool. Running code! I've linked it into my unix config page.
Great. Where is this web page?
I have some quick comments.
- your overview could be improved by describing how hiveconf is different
from gconf and the windows registry (and for that matter linuxconf, webmin, dotfile, etc.)
The OpenOffice presentation hiveconf.sxi describes some of this.
- I think samba is a great place to start. Presumably you could at some
point make up an unofficial patch which implements hiveconf as an option for samba. The simplest such patch might be just a symlink from smb.conf to smb.hconf!
Have you found out about /etc/hiveconf.d/samba.hconf? It makes it possible to use "hivetool" for reading/setting the Samba settings.
Making Samba use the Hiveconf API would be difficult right now, since there is not C library yet.
Samba has some things which are pretty interwoven and hairy to configure, for example guest access to printers but with security = user. It owuld be interesting to explore how metadata might be able to help novice and or expert sysadmins to navigate the samba config.
Yes, interesting.
- .hconf seems a bit clumsy to me as a file extension. .hiv ? But no
matter, it's your right as coder to choose such aesthetics.
Actually, the files were called ".hive" earlier, but the feedback I got was that this was a bad name. One advantage of .hconf is that it gives a hint of that the file is a configuration file.
This last issue is presumably where hiveconf might diverge from gconf, which (from afar) seems more oriented towards GUI apps.
Yes. Also, it has lots of dependencies to GNOME2:
$ ldd /usr/lib/libgconf-2.so.4 libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x42ce2000) libm.so.6 => /lib/tls/libm.so.6 (0x41152000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x427ff000) libdl.so.2 => /lib/libdl.so.2 (0x4114d000) liblinc.so.1 => /usr/lib/liblinc.so.1 (0x42d26000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x42505000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x42957000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x42472000) libc.so.6 => /lib/tls/libc.so.6 (0x41018000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x41e8f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x412af000)
All the best for your project!
Thanks.
On Wed, 25 Jun 2003, Peter Astrand wrote:
Congratulations. This looks pretty cool. Running code! I've linked it into my unix config page.
Great. Where is this web page?
I think you know it:
http://www.cat.org.au/maffew/cat/unix-config.html
I have some quick comments.
- your overview could be improved by describing how hiveconf is different
from gconf and the windows registry (and for that matter linuxconf, webmin, dotfile, etc.)
The OpenOffice presentation hiveconf.sxi describes some of this.
I just had a chance to look at that. That does explain things quite well.
I converted it to PDF, which I think will encourage more people to read it. See attached.
Have you found out about /etc/hiveconf.d/samba.hconf? It makes it possible to use "hivetool" for reading/setting the Samba settings.
Yeah I saw that after I emailed you.
Making Samba use the Hiveconf API would be difficult right now, since there is not C library yet.
Yes I understand. I was dreaming a little.
Did you see the part in unix-config.html where I talk about specifying the configuration file all in one place? I.e. a developer would list the configurable options, types, help text, defaults, etc. all in one place.
Then some scripts provided by hiveconf would parse it out into various sensible places, including hconf file spec & metadata, HTML docs, man page extracts, template config files, template code for the app to read in the config values, etc.
Possibly there could even be a mapping from different config variables into different parts of the code which use them. This mapping should be independent of any categorisation of options that the user sees. Indeed there might be more than one set of categories for users anyway. E.g. different app subsystems, beginner / expert settings, etc.
Ideally this would be done in a Makefile compatible way. I.e. a developer can use this master config file spec to make changes once and then run make and have them propagate into the rest of their project.
When I have been organised enough to implement systems like this for projects in the past, I've found it really cool and helpful and it encouraged me to keep things up to date.
A big challenge in encouraging adoption of a standard config system is to get developers to use it. So if there are major cool things for the developer then it's a big motivation. Once those things are in place, and you have a critical mass of developers, the other stuff like GUI editors (for developers and other ones for users) will follow.
Users want the features provided by hiveconf, but it is developers who must implement them by using a library like hiveconf when they start developing, or converting their existing code to be able to use it. So I think your main marketing challenge is to developers, not to users. You might gain a lot by looking at existing project's source code to see how they do config, and how to make it as easy as possible for them to convert their config handling code to hiveconf. (Maybe you already did this.)
This I think is a new way of approaching the problem, as compared to linuxconf and webmin which market themselves to users, and thus never seem to have the target app developers on board. They are always playing catchup with the apps. For a standard to work the changes have to propagate from the developers directly.
Gconf and the windows registry do target themselves at developers, and they have had a lot of success. But neither addresses all the things a Unix configuration system needs in order to be adopted by the diverse free software and open source community.
Maybe you have thought about all this, but I didn't see it in your notes so far.
This last issue is presumably where hiveconf might diverge from gconf, which (from afar) seems more oriented towards GUI apps.
Yes. Also, it has lots of dependencies to GNOME2:
$ ldd /usr/lib/libgconf-2.so.4 libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x42ce2000) libm.so.6 => /lib/tls/libm.so.6 (0x41152000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x427ff000) libdl.so.2 => /lib/libdl.so.2 (0x4114d000) liblinc.so.1 => /usr/lib/liblinc.so.1 (0x42d26000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x42505000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x42957000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x42472000) libc.so.6 => /lib/tls/libc.so.6 (0x41018000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x41e8f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x412af000)
Yes. All those dependencies scare me a little. Even on debian it is easy to mess them up. It is a lot to frag onto a server which doesn't even have X11 installed. Also it makes it harder to port to other OSes. Which I think is crucial. Some apps, like apache, have a large Windows user base! Requiring GNOME, probably implies cygwin too, which is a major dependency just to get configuration.
Cheers, Matthew.
(Sorry for the delayed response)
The OpenOffice presentation hiveconf.sxi describes some of this.
I just had a chance to look at that. That does explain things quite well.
I converted it to PDF, which I think will encourage more people to read it. See attached.
Thanks, I've added it to CVS.
Yeah I saw that after I emailed you.
Making Samba use the Hiveconf API would be difficult right now, since there is not C library yet.
Yes I understand. I was dreaming a little.
Did you see the part in unix-config.html where I talk about specifying the configuration file all in one place? I.e. a developer would list the configurable options, types, help text, defaults, etc. all in one place.
Yes, this would be a nice option. I think this can be done with hiveconf by using the meta-data feature (not implemented yet, though :-).
Then some scripts provided by hiveconf would parse it out into various sensible places, including hconf file spec & metadata, HTML docs, man page extracts, template config files, template code for the app to read in the config values, etc.
Exactly.
A big challenge in encouraging adoption of a standard config system is to get developers to use it. So if there are major cool things for the developer then it's a big motivation. Once those things are in place, and you have a critical mass of developers, the other stuff like GUI editors (for developers and other ones for users) will follow.
Users want the features provided by hiveconf, but it is developers who must implement them by using a library like hiveconf when they start developing, or converting their existing code to be able to use it. So I think your main marketing challenge is to developers, not to users. You might gain a lot by looking at existing project's source code to see how they do config, and how to make it as easy as possible for them to convert their config handling code to hiveconf. (Maybe you already did this.)
Good points. I think the next step would be a C-linkable shared library, and some enhancements to the Python implementation.
Gconf and the windows registry do target themselves at developers, and they have had a lot of success. But neither addresses all the things a Unix configuration system needs in order to be adopted by the diverse free software and open source community.
Maybe you have thought about all this, but I didn't see it in your notes so far.
I haven't thought much about it, but I think you are right.
-
matthew arnison -
Peter Astrand -
Peter Åstrand