HAL-Managers

[David Zeuthen]

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.)

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

and possibly other things. 

Also, such managers (bad word really) need, often, to interact with the
either the desktop, read per-user data (and do something sensible like
use system-, class- or site-wide defaults when no user is logged in) and
provide services to the rest of the local system and/or desktop session.

I have some things written down about how this can be approached in a
general way (using power management as an example), but it needs to be
cleaned up a bit before it's ready. I'll post it here in a few days.

Cheers,
David


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