jub at sun.com
Mon Mar 7 16:28:09 EET 2005
Sean Middleditch wrote:
> Unfortunately, D-Conf will not make easy and understandable GUIs
> magically appear for all D-Conf using applications. All it would do is
> create something similar to regedit or gconf-editor, which hard
> experience has proven are exactly the opposite of easy and
> understandable GUIs. They are administrator tools that exist ONLY
> because there is no other easy way to access the configuration stores.
> The nice and easy configuration GUIs must still be designed and built
> specifically for the target application.
But if there is a unified API for configuration data access and
manipulation that makes creating such a GUI easier. If I want to create
an administration frontend, I don't really want to create parsers and
generators for all the different configuration file formats and
> You don't need D-Conf to do that. The thing that D-Conf actually brings
> to the table and that are actually useful are:
> - Administrator control of user preferences
> (useless for system services, since there is no difference between
> default/user/mandatory settings)
Even for system services you may have a similar distinction: domain,
site or workgroup admins can provide default or mandotory settings for
an entire site or a class of machines that serve a particular purpose or
user group. Computer-specific configuration can be used to customize
this for a single machine or to add the settings you can't share.
> - Network transparency
> (I doubt you want that for system services, it would make them too
Even a desktop should still work as reliably as possible when the
network is down. OTOH there may well be system services for which you do
want some form of network transparency. You can't completely dismiss
network dependencies even for system services, otherwise there wouldn't
be systems like NIS.
But to me the real network transparency requirements aren't all that
clear yet: What should be transparent across what kind of network and in
> - Change notification
> (fairly unimportant, since you can just SIGHUP most system services
> after editing their config files)
Yes. Event/IPC-based change notification is primarily a desktop feature.
But even for system services it is useful to have an API to activate a
set of changes, instead of hardcoding the specific mechanisms to do this
for the various supported services in a configuration editor.
> - Ability to share settings between applications and let those apps
> change the settings
> (useless for system services)
I agree that system services usually don't change any settings
themselves (éxcept to store application state across sessions, for which
purpose configuration systems are often abused ). OTOH sharing settings
may actually be useful even for system services.
> - Existing API to reduce development time
> (this is the only one that makes sense for a system service)
In the end very much boils down to this. A unified data format for
frontends and archival also may make sense. Still it needn't necessarily
be the same API and data format for system and desktop configuration,
much less the same storage and implementation.
> Of those, the only one that's really helpful is the last, but it's not
> particularly *that* helpful. Really, all the D-Conf API would bring is
> a barely simpler replacement for open/read/write and some basic parsing
My experience is that that does make a difference.
> Most system services I'm used to have a lot of configuration that
> isn't just simple setting of keys, but things like writing out filters
> or setting a series of key/value pairs that have to make sense in
> context to each other. Again, D-Conf (nor any other configuration
> system) can't magically do that for you - you either need to know what
> to type in or have a GUI specifically built for the target application
> to assist the user.
But if you have a frontend framework and a unified api for the actual
parsing, generating and activation, then building a useful GUI for
another system becomes much easier and may in many cases be done in a
declarative fashion without requiring a C programmer.
More information about the xdg