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.