NB: Sorry for previous encrypted messages
I think one of the main benefits of the XDG_BASEDIR is that we can apply different policies to those folders, instead of having to go through each application directory. So to understand why (or why not) the XDG_STATE_HOME would be useful, I think we should specify the policies we might want to apply to each kind of file. In my opinion these are the distinctions that should be made about data: - is it lost if deleted ? If NO: go to $XDG_CACHE_HOME - can be deleted to retrieve disk space (no backup) - is it static configuration data ? If YES: go to $XDG_CONFIG_HOME - can be audited easily (+ backup + sync) - is it something that stores some application state ? If YES: go to XDG_STATE - can be removed to restore default state in case the application becomes unusable or startup crash (no backup) - can be synchronized between hosts to have a painless computer switching experience - else: go to XDG_DATA (for backup) In this regards, here is where I think the mentioned data should go: - application logs: XDG_DATA_HOME - user actions history (commands history, recent files): XDG_DATA_HOME - application layouts (different from view): XDG_DATA_HOME - session settings (opened files/projects, current view) used when restarting the application : XDG_STATE_HOME - sockets: this is a special case, because sockets should go in /run/user/$USER_ID. But some applications don't support variables in config files, hence it could go in $XDG_STATE_HOME Although we might want to implement retention policies on application logs and user actions history, file format heterogeneity would make it extremely difficult, so splitting this away from XDG_DATA wouldn't have a big impact. About your specific points: > Do you really think applications should store their log files in > $XDG_DATA_HOME? Personally, I don't like this idea at all. Why don't you like this at all ? I consider my command history to be important and part of the data I do backup on. How would you treat your history data differently ? > Some other > distinctions between data and state: > > - State data may not be portable. You wouldn't want it to sync across > machines. I agree, but if you application data is not portable, you might want to sync it between some systems and not others. And how do you judge portability (should work on all UNIX systems, on WINDOWS systems, ...) ? > - State data may be less important. A data loss here may be an > annoyance, but nothing as catastrophic as losing config or user data. How do you judge how data is important ? Some don't care about history, some do; some don't care about applications logs, some do, ... I don't think we can use this as a criteria for separating data in different folders. (We could however create a naming scheme to be followed by applications in the XDG_DATA_HOME). Overall, I don't think XDG_STATE_HOME should exist, considering the only two reasons (from my perspective) for it to exist would be: - exclude from backups (I don't think state data takes that much space, and some people might want to keep it) - synchronize between hosts depending on architecture and installed application version - I think applications should store state data in a folder with a unique scheme per architecture / version However, I think we should explicit the following usage for the CONFIG_FOLDER: - XDG_CONFIG_HOME is for static configuration not changing at each user session And add the following to the XDG_DATA_HOME: - user actions history files is data - application logs is data Initially, my main usage of XDG_BASEDIR is to not clutter my $HOME, so I would have liked to have a $HOME/.applications folder. But, there are advantages to have $XDG_CONFIG_HOME and XDG_CACHE_HOME: - the benefit from having XDG_CONFIG_HOME split from XDG_DATA_HOME is that you can use a VCS with it. - the benefit from having XDG_CACHE_HOME split from XDG_DATA is that you can regain disk space by deleting everything inside easily (no regex to target every cache folder in the application folder). However for STATE_DATA and HISTORY_DATA, backup and sync policies are different depending on user and application, so a single $XDG_STATE_HOME wouldn't improve the situation PS: I also think there should be another distinction, but that we shouldn't discuss it in this thread. - is it something that you want to keep out of disk space of this computer ? If YES: go to XDG_SECRETS_HOME - permit storing this folder with restricted access permissions on a different disk (or fetched online and stored in tmpfs) -- Best regards, Jonas DOREL _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg