XDG_STATE_HOME

[Allison Lortie]

hi David,

Thanks for your reply.  I'm back from holidays now :)

On Mon, Dec 26, 2016, at 14:25, David Faure wrote:
> 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.

I agree that this is useful, but it would be just as easy to blacklist
~/.var/cache from backups as it is to do ~/.cache/.  This is backup
*and* OCD friendly. :)

> 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.

Interesting.  I didn't consider pushing in this other direction as well.
 In practice, I guess this probably doesn't make sense unless you have:

 1) a standard for bookmarks used across the entire desktop
 2) support for expanding ~ (so the one in /usr can talk about your
 homedir)
 3) support for whiteouts so users can delete "system" bookmarks

either way, quite far out of scope with what is being discussed here...
but possible.



> 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?

More or less, yes.  This is exactly what I was thinking.  Trash may very
well be unique here.

> 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 ;)

I think of it more as "something that the system isn't interested in" or
"something that is not, conceptually, being 'installed' in any sense". 
Fonts, icons, desktop files, mime data, etc. are all very clearly in one
category while application data is very clearly in another.  The only
thing that blurs the line a bit, imho, is application plugins (which
are, indeed, "installed", but still app-specific).

> 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" ?

Indeed: I think the bigger problem for app authors will be deciding
between ~/.var/ vs. ~/.config/ but I think it is fairly easy to explain
that one.  Also: some people just don't care.  A big part of this is
providing a nice place that is *not* ~/.config/ for people who can't be
bothered to split out their config from their state.  We've clearly lost
the war of trying to force that separation on everyone.


I'll start drafting a patch to the spec over the next couple of days.


Thanks for the feedback,

Allison