XDG Default Applications specification proposal

[Simon McVittie]

On Wed, 22 Jul 2020 at 14:39:22 +0200, elektra at markus-raab.org wrote:
> Would you also see dbus for notification as implementation detail?

Yes; for Notifications, dbus *is* an implementation detail, but D-Bus
is not. (I'm being very careful with case combination and spelling here.)

The Notifications API requires using D-Bus, which is a protocol
that anyone can implement if they want to, like HTTP or X11. There
is a somewhat formal specification of how to find a D-Bus socket on a
freedesktop system, how to authenticate to it, how to exchange messages
(the "wire protocol"), and what the well-known system and session buses
are for. Notifications builds on top of that to define some specific
D-Bus messages.

The closest equivalent for a file-based interface, like Desktop Entry and
mimeapps.list, would be documenting what the files are, how to find them
(which is done by referencing the Base Directory spec rather than directly,
just like the way Notifications references D-Bus rather than specifying
how to find the session bus itself), and what their contents mean.

The D-Bus protocol specification isn't perfect (clarifications welcome
via merge requests!), but it exists, and is sufficiently useful that
there are at least four independent implementations that I know of.

The Notifications API specifically *doesn't* require using dbus, which is
the reference implementation of the D-Bus protocol. GNOME initially used
dbus for Notifications, and now uses GLib's GDBus, which turned out to
be a more suitable implementation for their requirements than dbus. Other
desktop environments might be using systemd's sd-bus, or even ndesk-dbus
(a reimplementation in C#). Notifications clients haven't noticed any
difference, and can continue to use dbus, GDBus, sd-bus or any other
implementation that they consider to be suitable for their needs, because
we have an interoperable specification that any implementation can follow.

This is the same as how (for example) Twitter's HTTP APIs require using
HTTP, but you can interact with them using libcurl, libsoup, wget, LWP or
anything else that implements HTTP; and as a user of that API, you don't
need to know whether Twitter is using Apache, nginx or something else.

If there is a single implementation that is optimal for *everyone*, then,
great, everyone can use that. X11 historically had many implementations,
but now Xorg is the dominant implementation (possibly the only one used
in practice).

However, we don't know ahead of time whether a single implementation
is going to be suitable for everyone. dbus was intended to be optimal
for everyone's D-Bus needs, which we now know is a really difficult
thing to achieve. Because dbus tries to be library-stack-agnostic,
desktop-agnostic, suitable for everyone's unusual requirements and
fully backward-compatible, it ended up being equally *unsuitable* for
everyone, and difficult to maintain and improve, to the extent that its
maintainers[1] frequently recommend using a different implementation,
like GDBus or sd-bus, that can be made more suitable for certain
use-cases by not being bound by the same constraints. For example,
GDBus requires dispatching the GLib main loop, and sd-bus does not allow
sharing connections between threads. Both of those are fine choices for
those particular implementations, which improve their suitability for
some uses, but neither of those design choices would have been accepted
in dbus, because our constraints are not the same as theirs.
That's fine, and not a bug: put different constraints in and you get
different implementations out.

> Or to put it bluntly: After DBus not much XDG *technology* happened
> anymore and XDG degraded to a discussion club, often about environment
> variables. And this despite the fact that environment variables are not
> well-suited and configuration settings are for a free desktop at least
> as important as inter-process communication.

I think you might be overestimating how much power "XDG" actually
has. There is no formal XDG organization, there is nobody who is
specifically paid to maintain or work on XDG, and, crucially, there is
nobody who can compel the maintainers of distros, desktop environments,
applications etc. to follow a particular specification by saying it's
an XDG standard. This is not the ISO, the IETF, or even POSIX.

An XDG specification has value if the relevant components (in this case
terminal emulators, and desktop libraries like GLib and Qt/kdelibs[2])
adopt it. If they don't adopt it, then the specification has little or no
value, because other relevant components can't rely on it.

In the case of a default-terminal specification, the only way it can
become useful is if the maintainers of major libraries that launch
.desktop files, for which the elephants in the room are GLib and
Qt/kdelibs, either merge an implementation that has been contributed to
them or write their own (which might reuse lower-level libraries, or not,
depending on implementation choices). If those maintainers decide the
specification isn't suitable - rightly or wrongly, it doesn't actually
matter! - then that makes it a lot less useful, perhaps even entirely
useless, because applications can't rely on it.

In my experience, a specification being tied to a specific implementation
is something that desktop environment implementors tend to be suspicious
of. It's more likely to be widely adopted if it's implementation-neutral,
like the proposal from Thayne that started this particular thread (which
is just spec wording, and doesn't come with an implementation at all),
or the older and more narrowly-targeted proposal from Vladimir Kudrya
(which comes with a reference implementation, but implementors aren't
required to use it, and I expect most wouldn't.).

To put it even more bluntly: it doesn't matter how much you like a
specification, and it doesn't matter how much I like it either. What
matters most is whether the maintainers of GLib and Qt/kdelibs (and
other implementations, but mostly those two) like it enough to merge an
implementation of it.

If there are particular aspects of a specification (file formats,
locations, semantics, whatever) that make life hard for you as an
implementor, then you're very welcome to suggest changes that make it
more straightforward, without losing the properties that it was designed
to have; but if they are at the level of "use this framework and it
will do everything you need" rather than at the level of interoperating
file formats, then I suspect that maintainers will tend to view that
in the same way as, for example, a Qt developer saying "everyone should
standardize on QtCore because it's great", or a GNOME developer saying
"everyone should standardize on GLib because it's great".

> Without Elektra becoming a
> dependency, Elektra will fail on the requirement to be available in
> every distro.

I could say: without GLib becoming a dependency, GLib will fail on the
requirement to be available in every distro. Does that mean Qt/KDE developers
should be willing to accept XDG specifications that are written in terms of
linking to GLib, and using GSettings or GVfs or something?
(This seems unlikely to happen; Qt/KDE developers have had the opportunity
to depend on GLib for literally decades, and have not done so, despite the
amount of code they could stop needing to maintain by doing so.)

Conversely, a KDE developer could say the same about Qt or kdelibs.
Does that mean GNOME developers should be willing to accept specifications
that are written in terms of linking to Qt, and using QML or whatever?
(This seems equally unlikely to happen, for similar reasons.)

Or substitute any other pair of implementations
(MATE? LXQT? Enlightenment? WindowMaker?) for GLib/GNOME and Qt/KDE.

>From an abstract, high-level point of view, the vaguely-defined
"freedesktop platform" would seem to benefit a lot from everyone agreeing
to use one particular library stack (or for that matter, one particular
UI toolkit, OS distribution or kernel), and yet this has still not
happened. I think we can conclude that for the people who do the work,
the (perceived or real) benefits of continuing to use their preferred
stack outweigh the benefits of standardizing on one implementation.
Not everyone has the same requirements, or the same priorities, or even
the same preferences.

Perhaps Elektra is amazing and everyone should be using it, but if that's
the case, it should be on its own merits, not because the nonexistent XDG
cabal says so.

I'm sure we've been here before with other frameworks, and I'm sure
we'll come back here again. Some get widely adopted as a dependency
(polkit, libarchive, NetworkManager, udev, arguably systemd); some are
used for a while, then later dropped when design or implementation issues
become clear, or just because they stopped being maintained (ConsoleKit,
Telepathy, gconf, ESD, ARTS); some never really make it at all (APOC,
Galago, Ytstenut); some are designed to be cross-desktop but in practice
are only adopted by a subset (dconf, tracker, folks); and some are widely
adopted but deeply controversial (systemd, again).

    smcv

[1] I am one of dbus' maintainers.
[2] I don't know which layer in that stack is responsible for implementing
    .desktop files, but whichever layer has their equivalent of GLib's
    GDesktopAppInfo, that would probably be the right place.