On Wed, 01 Dec 2004 21:43:24 -0500, Toshio <toshio(a)tiki-lounge.com> 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.
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
I'm open for other ideas in this space.