expanding the inhibit spec

[Lennart Poettering]

On Wed, 08.01.14 09:39, Ryan Lortie (desrt at desrt.ca) wrote:

> 
> hi,
> 
> On Wed, Jan 8, 2014, at 4:13, Lennart Poettering wrote:
> > 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...
> 
> The main issue of everything you've said is that it assumes that
> everyone will use logind.  That's your opinion about how the world
> should work, but I don't think we're quite there yet.

No, that is expressly not what I am assuming. All I am saying is that
this should be abstracted at the client side, and not in yet another
service in the middle. Because if you proxy all this, then you actually
break the one case that most of us actually care for (which is the
logind case)...

I mean, I am pretty sure that most other inhibition APIs would also try
to record who actually took the lock, and would thus be affected too if
you always proxy everything via some other daemon so that everything
looks like it came from the very same processs...

> If logind could put a service on the session bus which implemented a
> common API (ie: not one that was part of the org.freedesktop.login1 API)
> for this then I'd already be much happier.  I really think the session
> bus part is necessary because other people implementing this API are
> much more likely to be in a position to do it as a session service than
> as a system service.

I am not following here. What are you trying to do? THese are platform
APIs. D-Bus is not a plugin framework to make it possible to avoid
changing glib or gtk to support different platform backends directly.

I mean, what I am really not getting here: you are trying to abstract
something here so that multiple backends are possible. I assume you have
at least two backends in mind there? Which ones are those? logind is
one, but what is the other? It can't be Windows, since your proposed API
uses fd passing, but what is the other backend you want to abstract
here? FreeBSD? Do they even have an inhibition framewrk?

Abstracting this with just the vague idea that maybe one day there might
be a second backend, and that then maybe when that day comes it would be
better to run that on the session bus sounds just awfully wrong.

So, what precisely are you trying to make work here?

> Even that would not make me completely happy, however, because I
> couldn't handle all of my inhibit needs there (unless you were willing
> to expand the list of things you support inhibiting, for informational
> purposes for the session to see).

"things logind supports inhibiting"? what would those be?

I'd really prefer if you abstracted this in gtk or glib on the client
side. I mean, note that for some kind of inhibitors, like for example
the "idle" inhibitor the backend might not even be a bus service but
simly some local syscall. "idle" inhibitors are pretty close to android
wakelocks or suspend blockers in the kernel. It would only be natural to
expose them behind the same API. Wakelocks are cheap locks, programs can
take the often and for short periods, and you shouldn't need to involve
a mandatory bus service with that...

At the moment I can think of at different three different APIs that gtk
might want to provide a single API for: kernel suspend blockers, logind
suspend locks, and gnome-session screen-lock or logout locks. All of
them would greatly benefit if the actual client would talk directly to
them: to get the accounting right, to get permissions right and to get
the latency right.

Note that if you type "poweroff" on a systemd system right now, and some
desktop app "foobar" has taken a system shutdown lock, then poweroff
will actually tell you about that and tell you exactly which
process/user, and request you retry with "--ignore-inhibit" if you still
want to shutdown.... Please don't break this. it would be quite a loss
of usefulness if it would always say "gnome-session" as process...

Lennart

-- 
Lennart Poettering, Red Hat