[rfc] The Big Picture

[David Zeuthen]

On Thu, 2006-10-26 at 21:58 -0400, Samuel Cormier-Iijima wrote:
> I just wanted to make a point... I was thinking about something like
> this a few days ago; what if all daemons exposed a D-Bus interface
> that could be called (with appropriate permissions) from userspace?

You probably mean... 'desktop session' instead of user space.
Technically user space (AKA user mode) is anything that isn't the kernel
space (AKA kernel mode). 

> Things such as NetworkManager, gnome-power-manager, HAL all do this
> already and seem to be work well. However, I think that e.g. running X
> as two separate processes communicating events about mouse motion (!)
> through D-Bus wouldn't be the "ideal desktop," as it would slow down
> the computer alot. 

Maybe so.

> Anyways, even if the desktop was build like this,
> what benefit would it give to the user that doesn't already exist?
> Perhaps if the original poster mentioned some use cases, I would
> consider the idea more. Sorry if it sounded like a troll :-)

I think the interesting distinction to make is

 - "system" - entails both kernel and system daemons that expose
   mechanisms and knobs. Often such software does not make decisions
   (we also say they "don't enforce policy"); that is left to the
   sessions.
   Example: HAL, Avahi

 - "session" - typically run as an unprivileged user and often contains
   software that makes decisions (we also call say they "enforce
   policy") according to user preferences. 
   Examples: gnome-power-manager, NetworkManager applet,
             gnome-volume-manager, ...

It gets pretty interesting when you have more than one session which
e.g. happens with fast-user-switching. It also gets fun when you have
more than one physical console (this is where ConsoleKit comes in). 

In some situations you really want your software to be able to adapt,
e.g. the Banshee music player should probably pause when someone uses
f-u-s to switch to another user. Things like that.

Also, you want to be able to have a finely grained way of locking down
certain things for certain users in certain situations rather than
relying on the get-out-of-jail cards known as "user is at the console or
not" and "user belongs to some UNIX group" card (this is where PolicyKit
comes in).

But now I'm both off-topic and getting ahead of myself :-)

     David