screensaver and power manager dbus interfaces

[David Zeuthen]

Hi Kevin!

On Thu, 2006-06-01 at 20:10 +0200, Kevin Ottens wrote: 
> Le jeudi 1 juin 2006 00:01, Richard Hughes a écrit :
> > Okay, my first post to this list, so I hope I'm aiming in the right
> > direction.
> >
> > gnome power manager :		org.gnome.PowerManager
> > gnome screensaver   :		org.gnome.ScreenSaver
> >
> > This should probably be cross desktop and less gnome-y as there's no
> > reason another program shouldn't just drop in as a replacement for
> > either xfce, kde or just a slim-line gnome replacement.
> 
> In the following I'll assume that you expect the "org.gnome.PowerManager" to 
> be implementer by a session daemon since that's what g-p-m is.

Right, the spec for org.freedesktop.{PowerManager,ScreenSaver} needs to
specify that these services needs to be available on the per desktop
session message bus. Not the system message bus.

>  Although I 
> fully understand the need for a session daemon regarding screensaver, I'm not 
> sure I like the idea of a per session daemon for power management. 

It's not a spec for a power management / screensaver daemon, it's a spec
on how applications running in a desktop session can interact with power
management / screensaving in the desktop session on the system.

> I guess it 
> came from the fact that you started this as a desktop specific project, but 
> if we're going further with such a spec, wouldn't it be better to consider it 
> implemented by system daemons (HAL, powersaved, or something else)? 

My own view: System daemons should never enforce policy. The policy
needs to come from the desktop session or, in the event, no one is
logged in, from a copy of a desktop session daemon such as
gnome-power-manager that reads from the default/mandatory sections.
Presumably g-p-m would also integrate with the GNOME Display Manager
(e.g. login screen).

Having said that: this spec doesn't preclude anyone from implementing
system level daemons for power management and just have a proxy on each
session message bus that talks to the system level power management
daemon. Personally I think that is not the right approach but the spec
shouldn't preclude it.

> Otherwise 
> I feel that we'll end up with almost empty session daemons simply relaying 
> calls to a system daemon with more privileges... Moreover, since David hinted 
> about delaying the suspend, it looks more difficult to synchronize correctly 
> with several session daemons than with a single system one.

I presume you are talking about multi-seat and/or fast user switching.

I don't think the spec shouldn't concern itself much about this; e.g.,
it's up to an implementor to ensure that an org.freedesktop.PowerManager
service in one session doesn't e.g. suspend the system due to e.g.
idleness if someone inhibits an org.freedesktop.PowerManager instance in
another session. 

We *could* standardize on this in the future such that g-p-m and the KDE
equivalent in two sessions (both implementing o.fd.PowerManager) could
cooperate on not suspending the system. 

At this point I think it's too early to do.

> Maybe I'm missing something obvious here, so feel free to enlighten me in 
> order to make my concerns on this go away.

I think you are mixing up mechanism with policy. Either way I think it's
outside the scope of the spec.

Cheers,
David