Re: [Utopia] is gmv only ment for mountable stuff?

["John (J5) Palmieri" <johnp redhat com>]

On Tue, 2004-08-03 at 20:30 +0200, David Zeuthen wrote:
> On Tue, 2004-08-03 at 14:05 -0400, Joe Shaw wrote:
> > On Tue, 2004-08-03 at 13:44 -0400, Robert Love wrote:
> > > On Tue, 2004-08-03 at 13:31 -0400, John (J5) Palmieri wrote:
> > > 
> > > > My problem with this now is that it spawns a shell for every callout
> > > > script in the callout directories.  There is no intelligent routing
> > > > going on.  This is great for quick hacks but for the future when DBUS is
> > > > pervasive this will become a bottleneck.  Perhaps I should sit down and
> > > > write up in detail the idea for a pluggable policy daemon.  It extends
> > > > beyond HAL in usefulness.  Basically it eliminates the need to have
> > > > separate daemons running for each policy service (whether it be a HAL
> > > > policy or just some message coming over DBUS that envokes some sort of
> > > > policy).
> > > 
> > > OK, well this should be solved too - by DBUS activations.
> > 
> > d-bus can only activate as the user that the message bus is running as
> > (usually dbus or messagebus), and not as the user activating, so this is
> > out.
> > 
> 
> But you want all the policy handling to be at the session-level anyway,
> so the program being activated will run as the user logged in. One
> benefit of handling policy in the session rather than at the system
> level is that you have access to the users preferences from gconf.

Well there are instances where you need policy on both sides of the
stage.  For instance my printer configuration stuff goes like this:

User Session            || Root
======================= || ====================
printer plugged in      => callout hal_lpadmin
                        || autodetect driver
driver selection dialog <= driver not detected 
driver selected         => driver configured

=>, <= - DBus or Hal message

Right now I patching egg-cups to popup the driver selection dialog and
adding a patch to cups to listen for the driver selection since those
are already existing daemons.  However if there were no such daemons to
tack this code onto I would have to create a new daemon.  As it is I
don't even like the idea of patching cups as I doubt it would ever get
upstream.  With a policy daemon this is solved because I would just have
to add each piece to the appropriate daemon (session and root), even
implementing the configuration of the driver as a policy callout.

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com