HAL-Managers

[Kay Sievers]

On Thu, 2005-02-10 at 14:06 -0500, David Zeuthen wrote:
> On Wed, 2005-02-09 at 22:39 +0100, Kay Sievers wrote:
> > > I definitely think they have to provide their own "view of the world" as
> > > in "using HAL is an implementation detail" (but for me it of course
> > > makes sense for them to use HAL, otherwise they'll need their own
> > > solution for merging arbitrary information with hw (.fdi files), set up
> > > hotplug agents etc. etc.)
> > 
> > Ok, but how can applications know where to get that from? 
> 
> Presumably they would talk to com.foo.SomeService like certain apps are
> talking to the org.freedesktop.Hal service today.

Hmm, sounds a little bit like a kernel-developer argument. :)

> > We will get more and more virtual things, which should be handled in a
> > sane way from the beginning on. I don't talk about including all this
> > into HAL, we've already been there, but I really see the need for a
> > solution here.
> 
> I agree, but note that's pretty much what D-BUS is all about. Indeed,
> it's pretty difficult _not to_ end up with the model described above;
> services, objects, interfaces - all that jazz - that's the power of
> having a framework. 

I really think we should consider making the device store generic, put
it into a separate program on the bus and fill the device objects from
HAL. Any other "Manager" or CUPS can take HAL objects from there and set
properties or create own device objects from e.g. network devices.

Applications would only connect to that central "System Device Store"
and not directly to HAL.

All the fdi, callouts, property selections, subscription mechanisms
would be shared among all the possible "Managers" and applications have
a central repository and not just a bunch of addresses and don't need to
care about physical, logical, ...

Thanks,
Kay

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal