volatile config data and XDG Base Directory spec

[David Faure]

On Tuesday 13 August 2013 14:05:08 Jerome Leclanche wrote:
> On Tue, Aug 13, 2013 at 9:11 AM, Thomas Koch <thomas at koch.ro> wrote:
> > On Tuesday, December 04, 2012 04:35:12 PM Thomas Koch wrote:
> > > Some applications store "volatile" config data or "convenience data"
> > 
> > like:
> > > - last window position
> > > - recently opened file
> > > - last time application was run
> > > - ... you name it
> > > 
> > > Most annoyingly these applications create config files on first run even
> > 
> > if
> > 
> > > I won't ever run those apps again! So my home folder accumulates many
> > > worthless config files.
> > > 
> > > There are many examples of this in the .kde folder.
> > > 
> > > I don't like to really call this data "configuration". It's not
> > > intentionally set by the user. It has lot less value than "real hand
> > > crafted configuration" (think .vimrc, .emacs, .zsh, .gnupg/gpg.conf,
> > > .ssh/config).

That stuff isn't in XDG config anyway, so the argument doesn't really hold :-)
But yeah there's other stuff in there which is real config
(e.g. LDAP server for kaddressbook).

>  [...]
> Realistically, that's not feasible. The basedir spec is having a hard
> enough time being adopted as it is. Say we introduce XDG_STATE_HOME:
>  - Plenty of apps still create config files on first run, because that's
> just what they do.
>  - One more dotdir for $HOME, at very little benefit.
>  - More confusion for developers who want to use the basedir spec. "Does
> this count as state?" is a question they now have to ask themselves for
> every single setting.
>  - Most GUI apps use their toolkit's Settings class. State would have to
> either be managed separately or be implemented within the toolkit and
> specified declaratively somehow. Apart from window geometry, nearly none of
> it would be handled automatically; for the rest it would just be more work.
>  -> At this point, you're better off saving window geometry state in your
> WM config.
>  -> Falling short, there are ways to manage and clean ~/.config
> programmatically; that's one of the big bonuses of having this spec.
> 
> I've been a big evangelist of the basedir spec and I'm more often than not
> met with developers who (understandably) flat out refuse to split their
> config file into a dir, or multiple dirs ("cache is not config", ...). If
> on top of that you start telling them "But this type of config goes here!",
> they'll laugh at you.
> 
> In short: -1

Right.

On the other hand, configuration frameworks could be a bit more tidy in the 
way they store settings. I.e. without changing the spec, KDE apps (which were 
the initial complaint in this thread) could store state in separate files in a 
subdir of the config home.

The reason why "all KDE apps do this" is because it's done centrally 
(KMainWindow), so this could easily be changed in one place, and it would 
affect all KDE apps. Other frameworks might not do this (saving window state 
into the config file), so they might not need this spec change, this is why 
I'm suggesting to fix it in the implementation only.
Same for "recently opened files", KFileDialog does that, could be a separate 
config file too.

This would fix "keeping the real config in git" (just exclude the subdir).

OTOH it would incur a small performance penalty, opening and parsing more 
files than currently. But the files would be smaller, and e.g. one wouldn't 
parse the recent files until opening the file dialog or the recent files 
submenu.

> - an application isn't used anymore but the state data remains

Not much anyone can do about that, in any solution, but at least the real 
config wouldn't be polluted.

> - configuration is somehow managed centrally and the application doesn't 
> read configuration from /etc

And I don't really understand what was meant here.

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