while at linux.conf.au i spent a bit of time with tridge who was keen to showcase ldb which is the new "ldapy" storage backend that was written for samba4.
i've begun working on ldb support for kde and while i'm a few days away from having something worth committing so far it's looking pretty good. ian geiser had done some work on this already, i believe, as well. personally i've become convinced it's the way to go for kde4 and am putting in the effort to get it there. why?
ldb is an embedded database that mimics ldap. because it's embedded it's fast and memory lean. it had to be as samba has some pretty insane performance requirements. from what i understand, these performance requirements is what caused them (the samba project) to write their own thing rather than reuse something that was already out there. but it's features go far beyond performance:
firstly, it's transactional and multi-reader/writer safe. this means that if an app is writing to its config and crashes (or, as in a recent kicker bug report, the user purposefully kills it during such a write process) the configuration file doesn't end up in a non-usable state. it also means that even though everything is one file, it's perfectly suited to having dozens of different processes hammering away at it and all without having a separate daemon process.
it offers an ldap-y API and storage format but without the requirement of schemas (hallelujah!) and provides network access for free (just provide an ldap:// URI instead of a local ldb file path). they are now working on replication, so all users of ldb will get that for free eventually as well. indexes keeps access fast, and mmap'ing the file intelligently keeps page-ins and memory usage minimal. even the "two-phase commit" transaction system for writing is kept light-weight enough to not become onerous.
it's also scripting and human friendly. with command line tools and a "vipw"-like tool for the database, one can either use scripting or a text editor to edit the contents of the database (or any specific branch of it). this was one of my bigger worries (alongside safety) of using a monolithic binary file.
the obvious implications of all this are that kde could get a centralizable, replicatable, scalable, fast and safe config storage system that can move us beyond ini-style configs without much work on our part. being able to store data in binary formats also means that we may find we get some performance boosts from not having to ascii-ize everything on the way out to the config file and repeat the process in reverse when reading it in.
this translates into various perks such as making kde even more attractive for large roll-outs where centralization of config data may be desirable, making it easier for users to know what to back up ("just back up the kde.ldb file!") and bringing us a bit closer to integration with samba.
by providing a nice KDE-style front end to LDB we may also finally provide a nice way for app developers to store hierarchical data without resorting to abusing the INI file format (think mail filters or accounts in kmail, panel layouts in kicker) or deciding they need to use something else such as their own hand-rolled XML concoctions.
the latter is The Big Dream here. imagine a "firewall to phone" type solution based on the combined value of linux/bsd (firewall & operating system), kolab (groupware), samba (file/print), astrisk (voip) and kde (desktop productivity, document management, phone GUI and voice mail access) all with their configurations being held in a common LDAP(-y) database. so when the sysadmin adds a user they can get email, calendaring, file server access, network printer access, PBX access and desktop configuration provision all at the same time and essentially for free.
this obviously requires letting these individual pieces tie into the same configuration infrastructure, and it seems samba4 has the most sane option in our world right now from a desktop perspective. i talked with an asterisk guy at linux.conf.au about some of these things and will be discussing it with kolab people as well. and getting kde4 on ldb would be us doing our part to make this happen.
hopefully others will agree with me and we'll have ldb files as an option for configuration files in kde4 =)