Dear XDG List, 26.04.21 at 23:46 piegames wrote:
in discussions around applications adopting the basedir specification, the handling of non-Linux systems (especially Windows and MacOS) is something that really comes up a lot.
Yes. Env vars were obviously the most convenient solution for implementation/adoption but are a big compromise on many other aspects, even on Linux, e.g., with support of cron, at, sudo, ... It simply lacks an easy mechanism how to globally change the XDG variables and this is probably also the main criticism Windows+MacOS folks have, as they are used to have a global place to change configs "which simply works".
*Technically*, the specification is platform-independent, as it only depends on the concept of environment variables. However, this is not an accepted solution, as it is not native to these respective platforms. Instead, a common solution is to use the specification only on Linux and the respective native equivalents on other platforms.
I also think that XDG envs in its current form are practically not platform-independent (although I agree that they technically are). Which is also why Elektra https://www.libelektra.org has different resolving techniques for the path names of configuration files for different operating systems.
Thus, I have the following idea: if we set the default value for $XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective native equivalents for non-Linux platforms, it would make things easier to adopt on the application side. I am not sure if this is a breaking change, as the specification is not really explicit whether it even applies to other platforms at the moment.
I don't think the "setting the default" would be a breaking change, the spec does not say where the environment variables are set.
A disadvantage is that – at least on Windows – the destination paths are not computable anymore, and the Known Folders API needs to be called in order to get the values.
Yes, it would be a compromise but probably still be an improvement.As temporary (compromise) solution it probably makes sense to set the XDG env vars:
1. on Windows/MacOS with dedicated startup scripts reading from APIs like KnownFolders 2. on Linux with a script that gets XDG vars from Elektra to have a global place to set XDG vars, with the script executed at all places like login shells, desktop environment, at, cron, sudo, ...Btw. in Elektra we played around with intercepting getenv via LD_LIBRARY_PATH. The current implementation does not work in Windows but it would allow the return value to be computed at runtime.
https://www.libelektra.org/tutorials/intercept-environment But also this can only be called transition solution.As long term solution I would prefer to make the basedir specification independent of the implementation detail of environment variables, so that it can be directly integrated in Elektra.
Specifically, I would like to have https://www.libelektra.org and other portable config abstraction mechanisms to be completely compliant to the basedir specification, which would require allowing to get/set the XDG variables via other mechansims (not only env vars).
best regards, -- Markus Raab http://www.complang.tuwien.ac.at/raab/ TU Wien markus.r...@complang.tuwien.ac.at Compilers and Languages Phone: +43 650 480 4700 Argentinierstr. 8, 1040 Wien, Austria DVR 0005886
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
