volatile config data and XDG Base Directory spec

[Jerome Leclanche]

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.

In short: -1


>
> [1] http://debconf13.debconf.org/
>
> Regards, Thomas Koch
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>


J. Leclanche
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130813/535d82f3/attachment.html>