On Wed, 08.01.14 09:39, Ryan Lortie ([email protected]) 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
