Dear XDG folks, Am 22.07.20 um 08:16 schrieb Thayne: > On Tue, Jul 21, 2020 at 8:02 AM <[email protected]> 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 [email protected] Compilers and Languages Phone: +43 2619 21073 Argentinierstr. 8, 1040 Wien, Austria DVR 0005886 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
