So do I. You only need that feature if you want to, say, set a default wallpaper for new users or prevent them from changing, and I don't see any issues with they way it's implemented. It's a plain text config which can be deployed using your favorite config management system. You'd just put in a change hook like you'd restart a service after changing its config file.
> With the conventional one-file-per program approach the existing file system (instead of custom binary datastructures) is used to speed up the access.
The way it works is that dconf client mmap the database file, so it's the same. dbus does no caching by itself, it uses the same mechanism.
> A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus?
No, dbus is only used for writing. Reading is directly from the filesystem without anything in-between. The serialization format used by dconf matches the in-memory structure, so the application can literally take the value from (mmap) memory and use it as-is. So, no parsing.
I agree with you that it would be less efficient if dbus were used in the read path, this is probably why it's implemented that way.
> Not convinced. If most keys were read many times, something was very wrong.
> No. Most things are read by exactly one program.
> Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file
The primary use case for dconf are desktop settings and yes, those are read hundreds of time. Not only at startup, but also at runtime. The current GTK theme or scaling factor is read all the time during rendering.
I'm not advocating that all application config should end up in dconf - as I noted, I like my i3, GPG or SSH config the way they are.
For me, it has lots of practical advantages. For example, I have a script which sets all desktop settings the way I like them (font, scaling factor, focus follows mouse,...) and I can just set them using "gsettings set org.gnome.desktop.interface.scaling-factor 2" instead of figuring out which configs are in which files, how to parse them and merge existing and new configs.
> You'd just put in a change hook like you'd restart a service after changing its config file.
It's not the same. While servers restart on reboot, the config file is not automatically compiled. Also if you don't reboot, most servers are restarted through a uniform interface. Dconf makes an exception without need. You need the dconf infrastructure at deploy time (it might be an installation), and you need to know how to use it.
I've wasted hours figuring out how the configuration is to be used. In the end I still had terrible bugs. I'm glad other programs just do the parsing for me. It works, there never was a problem to begin with.
> The current GTK theme or scaling factor is read all the time during rendering.
I think you are missing the possibility of parsing a configuration once at startup and storing the result in memory in suitable datastructures. It's not like conventional programs would parse the configuration over and over. Fixed binary layouts are very bad for interoperation.
Btw, there is no memory usage problem compared to an mmap solution if every program just parses the _relevant_ information. And it also doesn't preclude a live-update mechanism -- this just has to be done with care. Not every information is trivially live-updatable, as illustrated by the breakage I mentioned.
> I can just set them using "gsettings set org.gnome.desktop.interface.scaling-factor 2"
This can be also done with text configuration files. Some programs do it. Most do it not (including dconf, which doesn't update your original input file) because the tradeoffs are bad. It has nothing to do with the question whether or not the serialization format is text.
Text vs binary is just this question: Do I need absolute performance or absolute discoverability? In the case of configuration files, the answer is clear.
So do I. You only need that feature if you want to, say, set a default wallpaper for new users or prevent them from changing, and I don't see any issues with they way it's implemented. It's a plain text config which can be deployed using your favorite config management system. You'd just put in a change hook like you'd restart a service after changing its config file.
> With the conventional one-file-per program approach the existing file system (instead of custom binary datastructures) is used to speed up the access.
The way it works is that dconf client mmap the database file, so it's the same. dbus does no caching by itself, it uses the same mechanism.
> A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus?
No, dbus is only used for writing. Reading is directly from the filesystem without anything in-between. The serialization format used by dconf matches the in-memory structure, so the application can literally take the value from (mmap) memory and use it as-is. So, no parsing.
I agree with you that it would be less efficient if dbus were used in the read path, this is probably why it's implemented that way.
> Not convinced. If most keys were read many times, something was very wrong.
> No. Most things are read by exactly one program.
> Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file
The primary use case for dconf are desktop settings and yes, those are read hundreds of time. Not only at startup, but also at runtime. The current GTK theme or scaling factor is read all the time during rendering.
I'm not advocating that all application config should end up in dconf - as I noted, I like my i3, GPG or SSH config the way they are.
For me, it has lots of practical advantages. For example, I have a script which sets all desktop settings the way I like them (font, scaling factor, focus follows mouse,...) and I can just set them using "gsettings set org.gnome.desktop.interface.scaling-factor 2" instead of figuring out which configs are in which files, how to parse them and merge existing and new configs.