expanding the inhibit spec

[Lennart Poettering]

On Tue, 07.01.14 13:16, Ryan Lortie (desrt at desrt.ca) wrote:

>  - not everyone is using logind
>  - the logind interface is on the system bus

On its own this one is a pretty pointless reason, no?

>  - it is labelled as being a "privileged operation"

Well, PolicyKit is used, and the default policy we install for that
actually allows all users that are logged in to at least get a delay
lock.

> The service that implements this in the session would surely need to
> communicate with other processes in order to coordinate this.  It would
> at least have to communicate with the process responsible for the
> screensaver to prevent it from being activated and with logind in order
> to forward information that it might care about.  I believe that this is
> a good argument for having a single "one stop shopping" interface
> instead of many finger-grained ones.  It's easier to use on the consumer
> side and on the implementation side, no matter what, there is going to
> have to be some forwarding of requests.

I am not convinced that passing these things around though a number of
layers is really a good design choice. I mean, abstraction for the sake
of abstraction is not somethign we should do.

The screensaver and logout inhibition logic is certainly something that
logind has no business with, and will never have any business
with. However, I'd claim it would be a better choice if the different
places where these inhibtors are implemented was abstracted behind a
single interface on the client side (e.g. in a unified gtk API) rather
than stacking layers upon layers in a variety of dbus services....

This is particularly a problem since logind's inhibition APIs will
actually record UID and PID of the client requesting these inhibitors,
and if the inhibition would be proxied via some session dbus service
then all inhibitors would appear as being owned by that proxy rarther
then the actual client. The UID/PID of the client taking the inhibitor
is both used for the Polkit decision and is available as queriable
metadata for other clients when they list existing inhibitors. (This
would also break a little feature I recently added to logind, which is
that i logs about inhibiting clients that delay suspend so long so that
the timeout hits. it would be a pitty if this was lost because
everything is proxyied via some other process).

> I'm sure there will be a lot of input on these ideas.  My plan is to
> just propose something that looks vaguely like logind's API, but on the
> session bus level, and based on application IDs (or desktop file names)
> but I will wait until hearing some feedback before proceeding on to more
> concrete proposals.

I certainly welcome standardization efforts for doing the
session-specific inhibitors, but I really don't buy the ideas of
stacking this on top of the lower level stuff.

If the lower level stuff is missing features, we can certainly add those
to the lower level bits...

Lennart

-- 
Lennart Poettering, Red Hat