XDG_STATE_HOME

[David Faure]

On mardi 3 janvier 2017 17:43:39 CET Allison Lortie wrote:
> 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. :)

I disagree. It's useful to be able to copy ~/.var from one machine to the next
(I need application state) without bringing the caches along (they can be 
recreated). If we don't make the directory structure convenient and we rely on 
blacklists then we might as well make a big mess ;)
 
> > 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

Not necessarily. This was about bookmarks for one specific navigator.
Still useful.

>  2) support for expanding ~ (so the one in /usr can talk about your
>  homedir)

I'm talking about web bookmarks, not filemanager bookmarks.

>  3) support for whiteouts so users can delete "system" bookmarks

The bookmarks being XML (XBEL standard), there is no merging happening. Only 
one file is loaded. As long as there is no local file, the global file is picked 
up. As soon as you create a local file (which is done by saving the memory 
representation, so the first version will include the global bookmarks)

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

My point is that it is already possible, and is a reason for thinking twice 
before moving too many things from ~/.local/share to ~/.var.
Unless we add XDG_STATE_DIRS for global dirs but it seems wrong,
for things that are actually state and not user data.
On the other hand there are of course other ways to achieve this, if less 
convenient (e.g. copying the initial file by hand).

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

Ah, that is another way to draw the line indeed.
With that approach, all "user data" (bookmarks, events...) would go to ~/.var 
too then.
I didn't think of it that way initially but I see the point: ~/.var is unique 
to the user (my own bookmarks etc.) while ~/.local/share would be limited to 
stuff I installed, which I could reinstall if needed.

> The only thing that blurs the line a bit, imho, is application plugins
> (which are, indeed, "installed", but still app-specific).

Plugins are architecture specific anyway so shouldn't they be in some sort of 
"lib64/plugins" directory? Note that plugins are not all app-specific, they can 
also be shared because loaded by a library. Anyhow I'm not sure why we're 
suddenly talking about plugins (and not executables, shared libs and 
everything else that is part of actually installing applications - but that 
doesn't typically happen in ~/.config, ~/.local or ~/.var anyway).

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

Well, let's see how you explain it so it's un-ambiguous :-)

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

You mean, for apps that don't split config from state, your expectation is that 
they will just move everything to ~/.var? What do we gain from that? And if 
they don't bother, they also won't bother changing the current situation ;)

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