Linux Registry, not only the issues side
hp at redhat.com
Sun Apr 18 19:46:30 EEST 2004
On Sat, 2004-04-17 at 09:54, Avi Alkalay wrote:
> I still would like to see GConf's numbers. XML is different.
I don't know if gconf is faster or not, but it doesn't really make any
difference; the reason for gconf's existence is not speed. And
discussion of ORBit dependencies or whatever sort of misses the point
too, which is overall design. You could change the dependencies, or the
file format, or whatever details you want.
My impression of the Linux Registry is that it's designed with
systemwide config in mind and does not do what we need for desktop
config, and of course gconf has the reverse problem (and is specifically
documented as unsuitable for systemwide config).
If you really want to get traction on this problem here are my
First the two reasons gconfd is a service not just a library:
1. You need change notification. Suggest D-BUS for this.
2. You need locking and transactions, especially with one
file per key (even gconf's one file per "directory"
causes lack-of-transactions problems).
4. Documentation/schemas for keys is nice.
5. There's an awful lot of desire to store config in LDAP.
A story on how/whether to do this is good.
6. In almost all cases a much bigger bang for the buck than
changing how configuration is done would be to eliminate
- autodetection and dynamic setup, e.g. of hardware
- ensure the configuration is done once per type
or role of system in an enterprise, not once per
It's also worth thinking about three kinds of data (from a desktop point
2. Session state (open windows, their size, etc.)
Recently my view is that your calendar and your email are documents;
i.e. they should appear to the user as a file that can be moved around.
This is in contrast to how Evolution currently works and how the above
gconf web site suggests it should work.
For systemwide configuration, we add a fourth kind of data:
4. Systemwide configuration
A successful design I think has to have a story for all of these kinds
of data. Not all of them need to be handled in the same way.
For example, perhaps documents should use something like GNOME Storage
(http://www.gnome.org/~seth/storage/). Or perhaps everything should use
Storage, who knows.
A question I think you should ask is whether it's worth compromising the
design for early boot; you may be able to do much better in the 90% case
by leaving the 10% case to plain text files.
More information about the xdg