XDG Default Applications specification proposal

[elektra at markus-raab.org]

Dear XDG folks,

Am 22.07.20 um 08:16 schrieb Thayne:
> On Tue, Jul 21, 2020 at 8:02 AM <elektra at markus-raab.org> wrote:
>>> * Reading the configuration format should not require linking to specific
>>>   implementation libraries
>>
>> This is "not invented here".
>>
> No, what library is used is an implementation detail, and should not
> be part of the specification.

If it is only an implementation detail, reuse is harder, the solution is
less flexible and the specifications get longer.

Would you also see dbus for notification as implementation detail?

> From what I understand of Elektra, it
> seems like elektra could support "mounting" the configuration for the
> default terminal using a specific plugin for this purpose, and
> applications and frameworks could use Elektra to read this
> configuration,

Exactly. In this case mounting or a specific plugin might not even be
needed.

> but the specification should not stipulate  that
> Elektra (or any other library) must be used.

In general software/technology reuse should be preferred, and in
particular XDG should endorse that.

APIs are a much more high-level way to access configuration than
describing the contents of files. Similar to PAM and /etc/passwd.

> If the best way to handle
> default terminal configuration is using something like Elektra's
> global key database, then perhaps there should be a separate XDG spec
> for that hierarchy, of which Elektra is an implementation (but not
> necessarily the only implementation).

Exactly, this is a goal of Elektra: to have specified configuration
anyone (applications, CM tools, admins, users...) easily has access to.

Without having some API, "easy access" is very far away.

>> Does anyone here actually care about the first sentence on the website
>> "https://www.freedesktop.org"? It reads: "freedesktop.org hosts the
>> development of free and open source software, focused on
>> interoperability and shared technology for open-source graphical and
>> desktop systems".
>>
> 
> Isn't that why we are here? To discuss an interoperable way for
> different open source desktop systems to launch applications in the
> user's prefered terminal.

discuss != develop

interoperable way != shared technology

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'm not sure how some of the items in your list of "useful
> requirements for a FLOSS ecosystem" support your argument for Elektra:
> 
>> - availability for popular distros
> Many popular distros don't have elektra in the official repos, and
> even if they do, it is not included in a normal install of most
> desktop environments.

Thank you for the input, I agree now: there is no way around this.

The "soft integration", where configuration files are mounted and
Elektra is optional seems to have failed. Without Elektra becoming a
dependency, Elektra will fail on the requirement to be available in
every distro.

>> - supports human-read/writeable configuration files
> All of the proposals so far have had this

Environment variables are not configuration files and they were proposed.

>> - several implementations in different languages exist
> afaict, libelektra only has one implementation, with thin bindings for
> several other languages.

Many parts of Elektra already have several implementations (plugins).
The small core does not have yet but a second implementation in Rust is
on its way.

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