On Wed, 2004-12-01 at 18:00 +0000, Cam wrote:
>>From the docs: "This method will block your program until one of the
> folowing happens:"
> I'm imaging it works by just re-reading the DB on each iteration.
> kdbMonitorKeys has to be a performance monster...
From looking at the sources, I think it does. But that's not the point.
And it's a bit harsh to judge the API on it's first implementation.
I think it's useful work to try and port apps to a common config API, so
long as the API is capable. Elektra seems to be written with the
assumption that the back end will be reimplemented, so maybe one day it
will. Until then, poor performance of some less-used parts of the API
shouldn't be a problem.
Having seen the first few incarnations of Elektra (then "Linux
Registry") and the initial community discussions with the author, I'll
have to disagree. Applications' needs came second, after the initial
design. Elektra is several iterations into the design. The goal needs
to stop being "get all applications to share a config database" and
become "how can we make configuring applications easier and more
consistent." A shared key-based configuration database is simply a
means to that end, and an implementation choice, not the end goal
itself. If it is made the end goal then you end up with, well, Elektra.
The API needs to be designed first and then the backend needs to be made
to fit. Currently, the API is built entirely around the idea of the
flat text key files. The KeyMonitor API is a perfect example of that
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.