HAL-Managers

[Kay Sievers]

On Wed, 2005-02-09 at 16:18 -0500, David Zeuthen wrote:
> On Wed, 2005-02-09 at 21:42 +0100, Kay Sievers wrote:
> > On Wed, 2005-02-09 at 11:04 -0500, David Zeuthen wrote: 
> > > On Wed, 2005-02-09 at 14:17 +0100, Kay Sievers wrote:
> > > > But for nice application support we will need something that can present
> > > > virtual audio devices e.g. network-audio or the alsa-lib created virtual
> > > > ones too, so that an audio player can present a nice selection list of
> > > > _all_ available devices and not only the real hardware. Something like a
> > > > MultimediaManager.
> > > 
> > > Right, would be nice - definitely outside the scope of this project
> > > though :-)
> > 
> > Is there any idea how to handle the namespace of such a solution? If we
> > have let's say a MultimediaManager who gets the physical sound devices
> > from HAL and keeps configured virtual sound devices from other sources:
> > 
> > o How can applications know where to get that info from? 
> > o Where are these devices/properties expected to live?
> > o Can HAL redirect requests to capability=="multimedia" to such a
> >   Manager or do we need some "Meta-HAL" for that?
> > 
> > The only really interesting thing for applications is a complete list of
> > device objects not only HAL's local ones. But if they are spread around in
> > some Manager daemon with an own namespace how is this supposed to work?
> > 
> 
> 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? Wouldn't it be
nice to have only one store with common access/subscription methods,
where the "Managers" store device objects in and applications can query
that.

> Look at NetworkManager - it knows (or it will) about
> 
>  - Networking devices (which it got from HAL)
>  - Available networks (there may multiple wireless networks available;
>                        you only have a network on a wired device if
>                        there is link/DHCP server)
>  - Tunneled connections such as VPN connections which needs to be
>    treated in a special way

Sure all this needs to be treated in a special way, but does it really
need not to be represented in a special way? I expect a lot of competing
things here, if we don't provide some sort of centralization.

So wouldn't it be nice if CUPS as an example exposes its list of
printers in the same form as HAL device objects, so an application may
ask some central instance where to get that list. The same question
applies to nearly all "capability" groups of devices.

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.

Thanks,
Kay

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