On Wed, 01 Dec 2004 21:43:24 -0500, Toshio <toshio@xxxxxxxxxxxxxxx> wrote: > On Wed, 2004-12-01 at 14:33 -0300, Avi Alkalay wrote: > > > Definitely. Elektra still has major short comings (no transactional > > > guarantees, no notification, no real access control, no temporary > > > keys... mostly things Elektra can never do since it refuses to use a > > > daemon), but it's at least a tiny step in teh right direction that might > > > open some peoples' eyes. > > > > Notifications is there already. Check the code. > > Avi, correct me if I'm misinterpretting, but the API docs seem to say > that Elektra has "monitoring" rather than true notification. > Notification as it exists in GConf is event driven (which is easy for a > programmer to use) and reasonably performant. The monitoring of keys > that Elektra's API implements places a much higher burden on the > programmer and seems like it would consume more system resources > (scanning for changes instead of being notified when a change occurs.) > > If the goal of Elektra truly is every program should use it to config, > then this is going to need some rethinking because few programmers who > need notification (at minimum, desktop apps) will choose the extra work > involved in Elektra over GConf. If Elektra is only aiming at the > current system services which don't change state dynamically (The app > "resyncs" with its config via restart or reload of all config info > rather than changing on the fly as each key is modified.) then it might > not need true notification... although I think there are system services > could benefit from notification; it's just that the capablitity to do it > isn't attractive with the current /etc files scheme. > > -Toshio > -- > Toshio <toshio@xxxxxxxxxxxxxxx> > > > The way GConf works is compatible with the layer GConf sits on: It is high level, (I think) it is integrated with an event driven framework (Gnome), etc etc. On the other hand, Elektra is very low level, in the same level as libc functions. If it was notification instead of monitoring, how it will notify a program that doesn't have an event loop? One way I can think is to install a callback and Elektra will create a new thread or process to wait for changes (remember we aren't in an event loop context) and call your callback function, but it will work inside a different thread and it can cause problems to your logic. So the solution I was able to think is to give you the basics (monitoring), and based on your program logic, you'll or wait for a change, or wrap it in a thread context that your program can handle. The way monitoring is implemented in Elektra is the best I could think for its descentralized nature. I'm open for other ideas in this space. Thank you, Avi
