ldb take 2

in my last blog entry i mentioned working with ldb for kde configuration. there was, as expected, a good amount of feedback most of which was negative. i thought i'd take a moment to address a few of the issues raised.

first the good news: kconfig was designed to have multiple back-ends available. i'm adding ldb/tdb as a possible backend; an env var controls which to use for now (makes it easy for testing things =). i see no reason to get rid of INI style configs altogether: applications still just see KConfig objects (so it matters not to them), and for other subsystems such as the services resources and application menu entry objects it continues to make sense to distribute those as INI style files. add to that the issues of migration from kde3->kde4 and the braindamage of NFS file locking and it just becomes pretty obvious that keeping INI-style config files as a backend is a no-brainer. that much was obvious to me from the start.

so there is no need to hyperventilate over INI files going away .....

some were concerned about storing the data in a binary format. people often go running and screaming from binary formats, and for some good reasons: binary formats have been home to some of the worst implementations of these things ever (e.g. the windows registry), and binary formats are usually impervious to text editors.

personally, i've worked with unix(-y) systems for years and really like a lot of things in them; being able to edit things with a text editor is among those things. if ldb didn't provide facilities for that, i wouldn't be interested in it.

but i do i believe it's important to separate failure from design; just because a particular airplane design tends to crash a lot, it doesn't mean that fixed wing aircraft are a bad idea when it comes to flight. so pointing to the windows registry (or gconf, if that's your axe to grind) and howling is not the most adroit means of evaluation here IMHO.

if you wish to edit your data via a text editor, you can certainly do just that with ldb using ldbedit (which launches $EDITOR).

and unlike the windows registry with its alice-in-wonderland-like maze of obscure entries with mysterious values, i'm keeping the same naming conventions so we can see "kickerrc -> general -> AutoHideDelay: 0" and with the beauty of kconfigxt even be able to see what the zero value means, what the range of allowed values is, etc...

and of course you can also export the db to plain text. that's how ldbedit works, actually.

but what about stability? well, ldb/tdb is being used by samba4 which in turn is being (or will be) used in some pretty heavy duty installations. when it comes to single sign on, printer access and file server stability failure isn't exactly an option nor is slowness. i'd also note that INI-style files aren't impervious to corruption either (as i noted, i just had a bug report on kicker about this exact problem last week), though they can keep it compartmentalized due to separate files.

so, how about the speed? that's the issue i'm working on right now. after years of using the same $KDEHOME, i have 181289 entries in 14066 groups spread across 386 files. cp'ing the rc files takes ~0.045s. migrating those settings over takes ~105s on my machine of which all but ~6s is spent in lbd_add, which amounts ~142 groups/second. kconfig's INI backend does it ~18s, or ~781 groups/s.

i need to do some more testing with realistic usage patterns and ensure i'm not using the API wrong and therefore tripping it up ... i also need to test read with appropriate indexes more before i can comment on those things.