Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 12:20 +0100, Aaron J. Seigo wrote:
<snip>
> For a widely implemented spec with API that is actually used, this would make 
> sense. This is not the case here, however.
> 
> > > So unless there's a really good reason for changing the name, I'd suggest
> > > we leave it, even if it isn't perfect (that being the enemy of good ;)
> > The good reason is that KDE's been using that name with this particular
> > API, with the expectation from application developers that such and such
> > function are working and will remain working.
> > 
> > Removing functions from the D-Bus API as you've implemented without
> > renaming it is akin to removing functions in a shared library without
> > bumping the soname.
> 
> As I wrote earlier, we can make this kind of change with the upcoming 5.0 
> release, so it isn't a problem for us. It is made much easier by the fact that 
> there is precisely zero usage of these calls in KDE applications according to 
> lxr.kde.org so would only be kept during the 4.x release series for API 
> discipline rather than any actual real world benefit. So this is not a good 
> reason to change the name.
> 
> The problem of having a KDE 4.x application work with a 5.x based env, or vice 
> versa, is a strong reason to keep the name as that does have actual real world 
> benefit.
> 
> .. which is why I asked if the motivation for changing the name is cosmetics. 
> :) If the reason for a name change is "a nicer name can be thought of" then 
> that just increases the cost for KDE. As a kindness to those who implement 
> such specs in a timely manner, it is nice not to heap additional work that 
> does not provide real world benefit when new implementions appear.

So, you can change the API because nothing uses it, but you can't change
its name because something *might* use it? I don't quite understand the
logic.

> > > > - As for the Inhibition APIs, gnome-session can inhibit more than just
> > > > the screensaver (log out, user switching, suspend, and auto-mounting):
> > > > http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.S
> > > > essi onManager.xml#n148
> > > 
> > > We already have /org/freedesktop/PowerManagement/Inhibit
> > 
> > We, as in, KDE? I don't see this being available anywhere on my system.
> 
> Perhaps; seems to be yet another API that got discussed (though I'm not 
> personally aware of when/where/between whom) and rarely implemented. :/

Where is it spec'ed?

> > >  for things like
> > > 
> > > suspension inhibition. It could make sense to try and unify all these
> > > suspension concepts into one DBus API .. though that could also just as
> > > easily be done in library API, preventing churn in the already
> > > implemented DBus services underneath.
> > 
> > I don't think that application developers should have to look in two
> > separate places for inhibition APIs. Having the API split like that
> > based on implementation details is just bad.
> 
> There are a couple ways to look at it:
> 
> * anything with the word "inhibit" in it, or which inhibits some system 
> functionality, belongs together in one API
> 
> * inhibition of system functionality belongs with the controller of that 
> functionality

Which brings back the question, why should application developers care?

> I lean towards the latter. We (KDE) don't have one overall "inhibitor" 
> service, but we do have a power management component, a screen locker 
> component, etc. With a unified inhibition API, we'd end up having to create a 
> synthetic service that calls out to these other services that implement the 
> actual functionality.

If this is the way we're gonna go, the implementation in GNOME is going
to stay in the "proxy" category. It's not usable to replace or even
supplement existing functionality.

> Having an inhibit catch-all service could easily lead to a random-collection-
> of-stuff API. It would also mean that each time a new can-be-inhibited system 
> service appears, we'd have to also manage a change to the catch-all API rather 
> than keep it localized to the service in question. (Ditto, but in reverse, for 
> system services that stop being offered, or aren't offered on specific form 
> factors.)

This is an implementation detail, users of the API shouldn't have to
care about where it's implemented or about the architecture of KDE. I
doubt that Windows or OSX split their APIs like that.

> What would be useful is to have a defined standard for inhibition API so that 
> each service that does support inhibition can be used in a consistent manner.
> 
> > And I don't see what log out, user switching or auto-mount inhibition
> > would have to do in PowerManagement.
> 
> They don't; I was discussing things like suspension which do :)

Yes... Which means that, if those additional ones were implemented, we
would have 3 additional separate APIs for it. I don't see this as being
useful.