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

[Dennis Heuer]

On Mon, 5 May 2008 13:09:50 +0100
Matthew Garrett <mjg59 at srcf.ucam.org> wrote:

> On Mon, May 05, 2008 at 02:05:11PM +0200, Dennis Heuer wrote:
> > On Mon, 5 May 2008 02:16:18 +0100
> > Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> > > Yes. A future in which we need a separate application to tell hal that 
> > > the USB device that's just been plugged in is a music player is not a 
> > > flying-car future. 
> > 
> > Sorry but there's no point in your statement. The real question here is
> > if hal is something ownstanding with backwards-strategies or if it is a
> > part of a system and treated that way. It's not just about hal but
> > about managing a system!
> 
> hal provides default policy when it is reasonable for hal to provide 
> default policy. hal should not be providing policy that needs overriding 
> - right now, it does in the case of X input configuration. That's purely 
> due to the lack of any other way of doing it at present, not because 
> people think the right way of doing things is to force people to edit 
> text files.
> 
> -- 
> Matthew Garrett | mjg59 at srcf.ucam.org

You still circumvent the real question. Your standpoint is fix and
nailed down to THE HAL, which does it for YOU ALL. However, default or
no default, the configuration of hal should be put into the hands of
the admin (or his system tools) and done at runtime. This said, the
development of fdi rules should not be done in an alchemist's
kitchen but as an own, open reference project. Here we come to the next
fix idea in your head: that defaults should come with the product and
should reside hidden on the disk for the internal case. I rather talked
about feeding hal's runtime-brain. This is also why the point that hal
would be in the need to trigger an external tool is a no-brainer. No,
the tool feeds hal with the rules whenever the admin (scripts) or user
(Desktop) thinks it's appropriate. This is like re-freshing hal's
brain! This is still before the music player is attached or
interactively after some rules for new hardware (or xorg) seemed to be
neccessary or shall be tested out. 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.

Dennis