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

[David Zeuthen <david fubar dk>]

On Tue, 2004-08-03 at 13:31 -0400, John (J5) Palmieri wrote:
> On Tue, 2004-08-03 at 12:58 -0400, Robert Love wrote:
> > On Tue, 2004-08-03 at 11:07 -0400, John (J5) Palmieri wrote:
> > 
> > > I think what we need for the future is something similar to xinet.d for
> > > services.  Basically have a single daemon that can efficiently route
> > > messages to different policy engines without them having to run as
> > > daemons.
> > 
> > HAL does this now via callouts.
> > 
> > It works great, but it runs things as root and not as the user.  I like
> > the current delineation between system and user-level, so I suppose one
> > idea is to add per-(logged in)-user callouts.
> > 
> > 	Robert Love
> 
> 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.  

I'm not sure this is true. Remember, the callouts in HAL is *only* for
OS vendors to maintain system configuration. 

True, it's still a lot of overhead; IIRC, Joe, who wrote it, initially
wanted to have a /etc/hal/callouts.d directory where you can put an XML
file describing some rules and conditions for a callout to happen. Which
I think we may want to do at some point.

> 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).  The policy daemon would route messages to the appropriate
> policy engine.  If the engine is not loaded it would be loaded.
> Subsequent calls to the policy engine would not need to incur the cost
> of startup.  Policy engines that are never used are never loaded and
> those which are loaded can be unloaded based on some caching criteria.
> An API for persistent storage would allow fast access for state
> information.
> 
> It is just an idea right now and perhaps there are other ways to solve
> the problem but every time the fix for a policy I need to implement is
> "create yet another daemon" I cringe.  Per-(logged in)-user callouts
> seems like an idea for getting rid of session daemons like g-v-m but how
> would it work?
> 

I think this should be solved by D-BUS activation at the session-level.

Cheers,
David