4 ms·
As far as I can tell the official reason for switching from gcong to gsetting is that the new backend is optimized for fast reading of config values. As for th
by vrotaru 15y ago
As far as I can tell the official reason for switching from gcong to gsetting is that the new backend is optimized for fast reading of config values.
As for the old schema, there were two options separate xml files in a directory per-app and a big consolidated xml file. There were some measuring showing that the second variant which was opening just a file and not 50 was a lot faster and considerably reduced startup times.
But now if you are going to put everything in a big pile of xml where it is hard to find and edit/remove/add options without a specialized tool you can as well use a binary format.
At least, that's my reconstruction of events.
- rbanffy 15y agoSo, the config system is slowly approaching a Windows registry... How about making opening the 50 or so files fast instead of putting everything into one big file and, then, into one smaller blob? Or we actually do like to make the same mistakes Microsoft does?
- jerf 15y agoRelevent, though I don't know what side I come down on: http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/65239... Sometimes pathological problems result in pathological solutions and I'm not going to step up and try to identify which spawned which. Goodness knows the happy UNIX story of happy text files configuring your happy isolated services has all kinds of horrific exceptions that don't appear in the happy part of the story, like Sendmail or .emacs.
- vrotaru 15y ago> So, the config system is slowly approaching a Windows registry... The config system may have been designed with Windows registry in mind, because Miguel de Icaza, the leader of Gnome project back then Miguel de Icaza (of Mono fame), was copying windows, and gconf-editor is a _registry editor_. As whether they'll make the same/worse/better mistake as Microsoft did, you guess is as good as mine.
- devs1010 15y agoInteresting, thanks for the info.. that said, you can still obviously read xml files into memory and hold them there if speed is the issue, I think its still easier to edit XML files rather than however its done with a BLOB (I've only used blobs myself when programming a Java app and persisting Java objects to a DB so maybe I don't have the full picture), anyways if they did that with XML they just need to expose mechanism to reload XML files after changes are made (to avoid needing to do a reboot, like Windows)