volatile config data and XDG Base Directory spec

[Dieter Plaetinck]

On Tue, 13 Aug 2013 14:05:08 +0100
Jerome Leclanche <adys.wh at gmail.com> 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).
> > >
> > > Do you have an idea for a name for such transient settings? Maybe
> > "state"?
> > >
> > > I'd really like to have an additional category besides CACHE, DATA,
> > CONFIG
> > > for this kind of settings. Having config and state mixed is mostly
> > > annoying if
> > >
> > > - one keeps config in a VCS (git),
> > > - an application isn't used anymore but the state data remains
> > > - configuration is somehow managed centrally and the application doesn't
> > > read configuration from /etc
> >
> > We've had this discussion again at Debconf[1] and discovered that several
> > people reported this issue on different channels. We agreed that it would
> > make
> > sense to add a third category STATE which goes into a place of its own.
> >
> > We don't think that STATE is the same as CACHE. The "backup test" is not a
> > good indicator. I could live with loosing the state data in an accident.
> > But I
> > keep my .cache folder in a tmpfs so that it does not persist across
> > reboots. I
> > would not like my STATE data to go away with every reboot.
> >
> 
> 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.


I think the xdg basedir spec has good ideals, and sure, it can take some work to adopt it properly.  But this subject comes up often enough to say it should be dealt with properly.
Having a spec that takes care of config, data, cache but not state (at least not in a proper way) makes the spec incomplete and what's the point of that?
Keeping the spec 3/4-complete as a "favor" to developers who are short on time/interest seems lame; I would rather finish the spec and if devs don't feel like implementing it all the way, they should at least accept patches from people who do.