XDG_STATE_HOME

[David Faure]

Hello Allison,

On vendredi 23 décembre 2016 16:32:55 CET Allison Lortie wrote:
> Take a look in your ~/.local/share/.  It's probably a mess.

How did you know? :-)

[...]

I agree with basically everything you said, except for this bit:

> One day we might also dream about moving the hilariously inappropriate
> ~/.local/share/Trash/ to ~/.var/trash/ or even ~/.cache/ to
> ~/.var/cache/.  See [1] for information on back-compat.

I don't think we want to move ~/.cache at all.

~/.cache is something you can wipe away, exclude from backups, and you won't 
have lost anything.
On the other hand, if you lose your future ~/.var, then you will have lost 
bookmarks, cookies, and so on. So that one, you do want in your backup.

IMHO the primary reason for a clean directory structure is to be backup-
friendly. The only other reason I can think of is, well, that we all have a 
bit of OCD with such issues :-)

One thing to note though: by using XDG_DATA_HOME for many things which are not 
initially thought of as a local override of a global dir, it still 
automatically opens the door for that. For instance bookmarks: we mostly think 
of them as local-only, but by saving bookmarks in XDG_DATA_HOME we 
automatically support pre-installing a bookmark file globally as a starting 
point for first-time users.

But yeah there are many things for which it doesn't make sense to have global 
data (recently visited links or files, autosave files, filemanager per-directory 
view state, locally stored calendar events, etc.), which would fit well into 
your ~/.var idea.

And indeed, the trash dir too, although you're right that migration will be 
problematic. Maybe we should start with changing implementations to support 
both dirs for a few years, and only then start ignoring the old one?

Conclusion: the tricky bit is going to be documenting exactly what goes into 
~/.var. "Application data for which it will not be ever be useful for it to be 
an override of a system-wide version of the data" doesn't read well ;)

And the question of "what is config and what is state" will pop up for sure
(I move a toolbar and Qt stores this as a binary blob, is that config or 
state?). Config is user settings (etc. configuration dialogs) while state is 
"other stuff apps want to save, which is not just a cache" ?

(where "cache" means: anything that only exists for performance reasons and 
that can be thrown away)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5