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

[Dennis Heuer]

On Tue, 6 May 2008 10:17:56 +0200
"Patryk Zawadzki" <patrys at pld-linux.org> wrote:

> On Mon, May 5, 2008 at 9:10 PM, Dennis Heuer <dh at triple-media.com> wrote:
> >  Hal should provide just a passive
> >  daemon (and probably one reference tool, if control is wished over
> >  the development of this feature). Instead, hal tries to have-it-all
> >  under it's own roof and manage-it-all the black-box way. This is
> >  backwards-thinking! Hal presents itself as THE future tool but keeps
> >  old, conservative strategies in the back. Your arguments remind me to
> >  distributors but not to free source.
> 
> Your description is closer to GConf which is a runtime configuration
> storage rather than HAL which is a hardware abstraction layer. And the
> abstraction layer means "no other tool needs to probe my hardware
> directly any more." It's not "every other tool should probe hardware
> and tell me about the results."
> 

What's wrong with you, guys? Please first READ the email before you
answer whatever you like. First, Matthew Garrett writes about a "flying
cars" future, as if hal were the future's engine and, consequently,
untouchable. However, what he isn't recognizing is that *his* flying car
is connected to the ground station via a cable. Now you write about the
difference between hal and gconf, as if the usecase would decide about
the question if a daemon should hard-implement a fileparser (and, thus,
everything else about the parsed files, like the format and the
installation location. Yes, even if the files are developed in an
alchemist's kitchen [controlled by distirbutors] is decided by that!)

Then you write that I wrote something like "every other tool should
probe hardware and tell me about the results." I never did! (Or, do
you mean hardware monitors? What's wrong with them?) What I wrote
stated that there should be concurrency in the hal-handling (feeding
hal with rules and controlling hal's state of knowledge), and that this
should be done after starting up hal (think of "udevd; udevadm trigger".
This is a different case but showing how an administrative tool is
overtaking the task of *parsing* a resource for some (already hooked
up, in this case) knowledge to be fed to the daemon *at runtime*.)

Do we come closer to the point now? Please re-read my messages the
serious way.

> Patryk Zawadzki
> PLD Linux Distribution

Ah, knew it! Why this is always so obvious?

Dennis