XDG Default Applications specification proposal

Wed Aug 5 15:23:20 UTC 2020

Dear XDG list,

Am 05.08.20 um 08:03 schrieb 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/?

Sounds like a very good idea.

> 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.

https://www.libelektra.org/plugins/resolver
https://www.libelektra.org/tutorials/merge-configuration

>> 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?

Take Single Sign-on Service as example. Of course it would have been
possible to only describe /etc/passwd and /etc/shadow. But such a system
would have been very limited and would not cover many use cases. Luckily
they refrained and described API and modules instead, so PAM is still
useful today. https://pubs.opengroup.org/onlinepubs/8329799/toc.htm

It is similar for configuration files. A system which would describe
specific configuration files in specific paths would be of very limited
use but disturbing in many other use cases (like when some application
or tool wants to change parts of this configuration).

>> 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?

I am not sure about mime types but some problems, like proxy auto-config
or fontconfig need some features which are not be directly expressible
with Elektra's API. In these cases --- if Elektra is the right tool at
all --- you need some additional API layer, e.g., to make queries easy.
So these cases are better not the first where Elektra should be adopted.

>>> 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

Yes, Elektra does it. To have the plugins in its own processes you can
use https://www.libelektra.org/plugins/process

> just an example though, there may be other cases where different
> applications have different needs for the core library).

Special needs for applications can be taken care of with adapters,
high-level or convenience libraries, like:

https://doc.libelektra.org/api/current/html/group__highlevel.html
https://doc.libelektra.org/api/current/html/group__kdbnotification.html

At the moment Elektra is not ideally equipped for configurations which
are not from configuration files. As this is not so relevant for FLOSS,
we keep it for Elektra 2.0.

And Elektra completely stops being useful if "configuration" cannot be
represented as key/value anymore but other databases have better
representations, e.g., location/GPS lookups. Furthermore, Elektra is not
the tool to represent state that should not be persisted. Elektra is
designed that the internal and persistent state are kept synchronous.

>>> 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.

Of course, that is why we currently focus on KDE/GNOME adoptions next to
finalizing the specification (Elektra 1.0).

>> 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.

Elektra supports D-Bus https://www.libelektra.org/plugins/dbus

>> 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.

Probably the applications simply added operating systems specific code
(e.g. for finding the equivalent for $HOME) or simply do not work there.

>> 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.

Which file format do you mean?

> To be clear, I think elektra is a really cool concept, and I hope it
> is successful.

Thank you :-)

> However, I don't want the simple problem of specifying
> a default terminal application to be a pawn in pushing elektra into
> greater usage.

This was also not my intention. Initially I wanted to point out that:

1. agreeing on requirements should be done before implementing something
2. specifications can be done on different levels, not only with files

> 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.

In the long run it should be okay to depend on Elektra, even when
reading only a single value. But at the moment, I agree: better do not
require Elektra in your spec proposal.

> 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

Very good idea, I updated the page.

> all, using elektra for all configuration makes a lot more sense than
> using it for a single config key :).
Of course!

best regards,
-- 
Markus Raab          http://www.complang.tuwien.ac.at/raab/
TU Wien                   markus.raab at complang.tuwien.ac.at
Compilers and Languages          Phone:      +43 2619 21073
Argentinierstr. 8, 1040 Wien, Austria           DVR 0005886