Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Toshio]

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 at tiki-lounge.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20041201/bd7c1111/attachment-0002.bin