XDG Default Applications specification proposal

[Thayne]

On Fri, Jul 31, 2020 at 10:17 AM <elektra at markus-raab.org> wrote:
> Elektra has many specifications:
>
>  - its API: https://doc.libelektra.org/api/
>  - a >300 pages book capturing the meta-specification
>    https://book.libelektra.org
>  - many grammars that specify different configuration file formats
>  - different protocols and technologies that ensure that applications do
>    not overwrite each others configurations
>  - different ways to locate the configuration files on different
>    operating systems (like XDG Base Directory Spec)
>

So why not propose adding these specifications to the umbrella of XDG?
Perhaps as an alternative to
https://www.freedesktop.org/wiki/Specifications/config-spec/?

Also, where are the "protocols and technologies that ensure
applications don't overwrite each others config" specified? I haven't
been able to find that.

> After this long journey, I can say with high confidence that it is not
> feasible to specify how to get or set a configuration value.

Why not?

>
> What is feasible and done by Elektra is to specify an abstraction,
> comparable to a virtual file system (which allows mounting the
> configuration files) and an API that allows access (like the
> open/read/write/close API for filesystems).
>
> > 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
>
> Trying to specify this would be as difficult as trying to specify how an
> virtual file system works and leave it "up to the implementation" to
> find the file systems on the hard discs and then to locate files there.
>
> This might work for reading files (e.g. grub does it) but if you also
> want to modify something, you will get very lost very soon.
>

How is the problem of a default terminal application any different
than desktop entry or mime types in this respect?

> > 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.
>
> Yes. In Elektra there are many such situations and thus also many plugins.
>
But what if libelektra-kdb itself doesn't meet the needs of an
application? For example, what if the application needs to isolate the
plugins in their own processes, so that if they crash they don't take
down the parent process? (Maybe elektra already does this? This is
just an example though, there may be other cases where different
applications have different needs for the core library).


> > I think you might be overestimating how much power "XDG" actually
>
> Quite a few things from XDG are heavily adopted. And there is no
> alternative to XDG anyway?
>

And some things from XDG  aren't.  XDG could make a spec that requries
elektra, but if the big players don't want to integrate with elektra,
it's not going to be adopted.


> Yes, I suggest such changes. I do not think that the filesystem is a
> suitable abstraction to specify configuration in the same way as the
> filesystem is not the suitable abstraction for databases. E.g. SQL is
> one suitable abstraction to access relational databases. I think Elektra
> API a suitable abstraction for configuration.
>

Elektra is not the only way to provide such an abstraction though. For
example, a D-Bus API rather than a C/C++ API could work just as well.

>
> Interoperating file formats are not the solution for everything, in
> particular they are not well-suited for interoperability of
> configuration because:
>
> 1. it is impossible to agree on where the files are, as different
>    operating systems have fundamentally different requirements.

Hos is that impossible? Multiple XDG specs specify where files are,
and it works well enough.

> 2. specifying configuration file formats with the properties we want
>    (order-preserving, comments-preserving, ...) is way too hard and in
>    the end also a matter of taste (like filesystems).

The other proposals have all used basically the same file format as
existing XDG specs.

To be clear, I think elektra is a really cool concept, and I hope it
is successful. However, I don't want the simple problem of specifying
a default terminal application to be a pawn in pushing elektra into
greater usage. I fear that would result in achieving neither goal,
since it is a hard sell to add a dependency on elektra just to read a
single config value.  I think that the "Shared Configuration System"
specification currently in "planning/requirements-gathering" phase
would be a better place to discuss adoption of elektra
(https://www.freedesktop.org/wiki/Specifications/config-spec/). After
all, using elektra for all configuration makes a lot more sense than
using it for a single config key :).