volatile config data and XDG Base Directory spec

[Dieter Plaetinck]

On Thu, 22 Aug 2013 08:27:21 -0700
Thomas Kluyver <takowl at gmail.com> wrote:

> On Aug 22, 2013 6:17 AM, "Dieter Plaetinck" <dieter at plaetinck.be> wrote:
> >
> > 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.
> >
> 
> But who's to say there are only 4 categories? I'm sure we could come up
> with 5, 6, or more quite easily. There are all kinds of ways to distinguish
> different data. The emphasis should be on what is useful for devs and
> users, not on matching some mental model of different kinds of data. And
> part of being useful is getting devs to adopt it. An imperfect but widely
> used standard beats a perfect standard that half the devs ignore any time.
> 
> I'm not saying adding a fourth category is wrong, but I think it should be
> justified in terms of practical value and chances of adoption, not just on
> theoretical grounds.
> 

I agree, but the proposal for a 4th state category comes up often enough;
i haven't seen anyone advocating a 5th or 6th category.