should service providers like hal and udev have own scripting engines and script folders???

[Dennis Heuer]

Don't understand me wrong? You can do whatever you want. However,
weren't services like udev and hal developed for "dynamic runtime"
configuration, and aren't fdi files and stuff rather leading into the
opposite direction?

I mean, those scripts are "parked" in product-specific directories and,
even in the case of them residing in /etc, this is done in a fully
product-specific way. The scripts are written in some product-specific
scripting style, for which the daemons must hard-implement file parsers
instead of just listening to network communication. Nevertheless, both
hal and udev support triggering scripts. Ok, shutdown doesn't have a
dbus address yet, but does hal have to solve this problem?

In the very special case, this very ownstanding, static, and hideous
strategy can make things rather complex or even unsolvable without
something unintuitive like a text editor. This is not neccessarily
because of the services, but when other projects don't play well, the
solution to the problem is everything else than configured dynamically
at runtime.

I currently have a problem with my cherry keyboard. The xorg server
recognizes it via my configuration in xorg.conf. However, the evdev
module overwrites the settings with what is read from hal. For whatever
reasons, hal doesn't respect the locale of my system as well as the
physical keyboard layout but tells xorg that the keyboard layout is
"us", which is wrong. For some other reasons, my desktop is not capable
of re-setting the layout. So I switched back to the kbd driver. However,
the evdev module just overgoes the kbd module. What now? At the xorg
buglist, they told me to modify an fdi file in hal's repository. I now
ask you if this is an intuitive way of configuring the keyboard for my
desktop environment? And, is there--at all--any intuitive way of
manipulating fdi files?

Ok, this is not your problem, I hear you say. But it made me think
about what I already wrote above. Doesn't the scripting part of hal and
udev rather do harm to the idea of dynamic runtime configuration? Isn't
it contradicting to the projects' goals? Schouldn't there rather be a
small system tool with which I could tell hal that my cherry keyboard
has a different layout--at runtime? Manipulating the fdi file doesn't
do anything until a replug of the keyboard or a restart of the system.