RCF: Basedir specification for non-Linux

[elektra at markus-raab.org]

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.raab at complang.tuwien.ac.at
Compilers and Languages          Phone:    +43 650 480 4700
Argentinierstr. 8, 1040 Wien, Austria           DVR 0005886



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210427/0e469534/attachment.sig>