Hi! I just released libcanberra 0.9:
http://0pointer.de/lennart/projects/libcanberra/ Biggest change is a new lookup cache that minimizes disk seeks when we look for a sound. Previously a sample lookup resulted in quite a few disk seeks, since we had to look for files in all kinds of combinations of locale, output profile, name, event ids, file suffixes ... The lookup cache now does both positive and negative caching of sound paths. This way the number of seeks necessary to find a file goes down to only one or two. The cache is basically just a small database file that is accessed via Samba's "trivial database" system. Why did I choose tdb and no other implementation? First, it's tiny and it fulfills what we need here. The primary reason however to pick it over gdbm/ndbm/... is that it allows concurrent access (although gdbm does locking, it only supports a single global lock that is held during the time the db is opened, which is unsuitable for us since we want to share the cache between processes). Also, it is actively maintained, is well established and has a stable API. I know that this is a controversial issue. To minimize the impact of this choice, i made this dependency optional. If tdb is not enabled during compile time, lc will be built witout lookup cache, i.e. behave very similar to older versions. Also, I made sure to seperate the actual db access into three very simple functions. If people feel that tdb is not an option for them it is relatively easy to port lc to another db system. Please note however that that db system needs to allow concurrent access, too. I'd be happy to merge a patch that uses #ifdef to make this alternative db system optional. Possible systems could be SQLite or Sleepycat. However, SQLite is rather large for this task and Sleepycat has this horrible story of breaking compatibility. However, if your distro already includes one of these databases but doesn't include tdb it might make sense to port lc to one of them. Please note that tdb is actualy used by quite a bit of software these days outside the Samba universe. It is actually very hard to install a system without it these days. Usually however, people tend to copy tdb into their sources -- which I however chose not to do since this means problematic updating on bugs, and needless code duplication. Also tdb nowadays comes with a pkg-config file and everything, so I see no reason why we shouldn't link dynamically to it. I hope this explains why I chose tdb and why I think this is a good choice. Even though this kind of adds a (soft) dependency of libcanberry on samba, since tdb is shipped as part of samba. Comments, opinions? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
