On Tue, 07.01.14 13:16, Ryan Lortie ([email protected]) 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
