org.freedesktop.PowerManagement

[David Zeuthen]

On Sat, 2007-03-31 at 10:07 +0200, Lubos Lunak wrote:
> I'm still not quite sure Inhibit() even belongs to PM interface, I
> cannot think of a single case when an app would want to block suspend
> but would not want to block logout, so it'd always have to block both
> of them. However the SM semantics (at least as they're in XSMP)
> wouldn't allow blocking PM suspend by blocking SM logout. Not that I
> have any better idea.

There are at least two classes of applications

a.  Apps that want to cancel logout; this could be some number-crunching
    application that just operates on local files that lives in the
    home directory of the user. These apps don't care if the system is
    suspended/hibernated, but they do want to cancel logout.

b.  Apps that depends on entities/services external to the session; e.g.
    networking and devices. This includes 1) disc burning (you get a
    coaster if you suspend the box); 2) downloading files (may take
    hours so you don't want the box to suspend because the session
    becomes idle); 3) probably other examples.

Apps in class b. justify the Inhibit() method; they want to more than
just block logout; their operation depends on external entities that may
disappear if the system e.g. suspends / hibernates.

So I think it's like this: 

 - Apps in class a. should just use XSMP (or Inhibit() on the proposed
   org.fd.SM D-Bus interface); and 

 - Apps in class b. should use Inhibit() on the org.fd.PM D-Bus
   interface. 

And as you note b. surely implies a. so the 

 - org.fd.PM spec needs to say that PM daemon implementing this
   interface should/must use XSMP to delay and possibly cancel logout
   if, and only if, someone is inhibiting the PM actions. 

 - the docs for Inhibit() needs to specify that the PM daemon will
   delay/cancel logout via XSMP on behalf of the caller. This is
   important because application authors need to know that they don't
   have to do this themselves.

Sounds about right?

> > Specifically, as you mention, existing PM 
> > daemons like gnome-power-manager, kpowersave etc. would just provide
> > both "interfaces" until something better comes along to provide
> > org.freedesktop.SessionManagement, e.g. for GNOME it . Notably we can
> > extend this interface later on.
> 
>  Yes. A session management providing merely shutdown/reboot/logout is vastly 
> insufficient and would basically just use the XSMP-provided functionality 
> (plus whatever starts the shutdown/reboot afterwards). I originally suggested 
> the org.fd.ShutdownManagement name because of this but if this is meant to be 
> extended somewhen in the future than I think it can be called 
> org.fd.SessionManagement.

Maybe we just punt org.fd.SessionManagement and tell apps in class a. to
just use XSMP? I mean, at _some_ point someone will write a spec for
org.fd.SM or similar so apps can migrate from XSMP to something better
and I don't think we should make it harder for them by defining parts of
their interface in advance.

     David