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>
Attachment:
signature.asc
Description: This is a digitally signed message part
