Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 13:56 +0100, Aaron J. Seigo wrote:
> On Thursday, November 29, 2012 12:50:34 you wrote:
> > On Thu, 2012-11-29 at 12:20 +0100, Aaron J. Seigo wrote:
> > So, you can change the API because nothing uses it, but you can't change
> > its name because something *might* use it?
> 
> No :)
> 
> The API can be changed in 5.0 as we can break compatibility there; since 
> nothing actually uses the API that would be removed the real world development 
> cost will be 0.
> 
> Changing the name of the service incurs development cost as we will need to 
> support the case of mixed application and service versions. The only way to 
> prevent that is to keep both names in perpetuity, and I don't see any point to 
> that unless there is something seriously flawed with the existing name.

In the implementation it's:
if (path == old_service_name)
  do_old_stuff
else if (path == new_service_name)
  do_new_stuff

Where most of the code between do_old_stuff and do_new_stuff would be
shared anyway.

> > > > >  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?
> 
> It's more "why should the implementors care".

No, I'm making an API for application developers. System developers and
implementors make do with whatever they have available.

>  If application devs don't care 
> (though if they are going to use DBus APIs directly, they will), then it's 
> what is most convenient and maintainable for those of us writing the 
> implementations.
> 
> Having one catch-all inhibit service is more work and harder to maintain, 
> which is why I care as one of the people involved in implementing these 
> services for KDE :)

It took me an afternoon to write this proxy. Don't you think you're
exaggerating the amount of work here? Certainly, it would go well with
the other pieces of abstraction you've already got in your stack.

> > > 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.
> 
> Yes, which is why I don't like the catch-all approach and prefer a per-
> service-inhibition API, e.g. one for power management, one for screen locking, 
> etc.

The current API is severely limited, and non-extensible.

> > > 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
> 
> It has nothing to do with users of the API, but rather the specification itself 
> which we who are implementing it will have to maintain.

If you write API for the implementors, it's no wonder the API ends up
being as muddled as this, with no clear separation between app-level API
and system-level API.

> > > 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.
> 
> Log out and user switching are probably connected.

Or maybe not, if I offer user switching in the screensaver, do I talk to
the screensaver? The display manager handling the switching? The desktop
daemon that'll make sure the current session is locked?

> Auto-mount inhibition (btw, what's the application level use case for that 
> one) would belong with hardware awareness support.

VMs, disk management at least. Probably music players or movie player
("Insert disk foo" or "Plug in device so and so").

> So 2 APIs. Which, if we have a standardized API for inhibition means we only 
> need to determine the service name. e.g. org.freedesktop.sessionManagement (or 
> whatever)

2 *more* APIs. That's 5 inhibition types and 4 separate APIs, 4 separate
documentation, with 4 separate possible types of bugs and semantics.

This is what the API should look like from the developer stand-point:
http://developer.gnome.org/gtk3/3.6/GtkApplication.html#gtk-application-inhibit

> With service names in hand, whether it is implemented all in the same place or 
> by multiple processes (or whatever) becomes an implementation detail. If one 
> process implements ALL this functionality, then it just registers the various 
> interface names on the session bus.  If it's multiple processes, then each 
> responsible process handles the relevant interfaces. This facilitates either 
> development strategy in a way that makes it an "irrelevant" detail to both the 
> platform and application developer.

The "one documentation" point is very relevant to application
developers, and the failure to come up with comprehensive yet simple
APIs that don't leak out the implementation details makes us (Linux/Unix
system developers) look amateurish.

<snip>
> The downside is that if one wants to inhibit "everything" then you need to find 
> the set of inhibitable services, though with the command line tools a very 
> small amount of scripting this is easy *if* the inhibition API pattern is 
> standardized.

Again, the problem isn't the 3 more lines of code, it's the
documentation, and the cohesiveness of the API. Having 4 separate APIs
implemented in 4 different ways isn't going to help with that.

Cheers