What constitutes "user configuration files" in the XDG basedir spec?

[Dieter Plaetinck]

On Wed, 4 Mar 2009 14:59:02 +0100
Axel Liljencrantz <liljencrantz at gmail.com> wrote:

> 2009/3/2 Dieter Plaetinck <dieter at plaetinck.be>
> >
> > It's always hard to define those things in words, but I think the
> > wordings @
> > http://lists.freedesktop.org/archives/xdg/2009-February/010191.html
> > are quite good. (and plenty of examples).
> >
> > I'm trying to hard to find the use cases where it may become blurry.
> > I was thinking of an ftp client: if you store a recently
> > visited ftp server it could be state, but it contains a password so
> > you might call it data as well.  OTOH if you think the password is
> > that important you could make a "bookmark" and then it would be
> > data, this is a good solution I think.
> >
> > Can you come up with examples where it might blur?
> >
> 
> 
> I can.
> 
> Fish, the shell I'm maintaining (regular command line shell, like
> bash) has a feature called universal variables, where you can set
> environment variables so that all your users fish instances on that
> machine will get the updated value at once. (Very useful for
> configuring your shell without forcing you to re-source your init
> file in every running shell or e.g. sharing ssh autentication between
> all your shells) The value is also saved to disk, so that it remains
> on reboot. The file used for storing these variables, is it state or
> configuration? As near as I can tell, environment variables are
> frequently used for storing both.
> 
> Axel

Imho that would fall in the config section, because the user configured
the variables explicitly.  Note that state vs config is not about
persistent vs not-persistent.  "State" and "config" (just like "data",
"cache" etc) are meant to categorize files.  The fact that
in your case your variables are first in memory and persisted to disk
only later does not change their "nature" (which is config, imho)

This also complies with Guillems "definition" (which was at the time
probably more a draft but I think it works well) of config:
- settings one edits directly on a file,
- changes explicitly through a command line tool (your example)
- changes explicitly on a preferences or settings dialog in TUI or
  GUI apps.
( taken from
http://lists.freedesktop.org/archives/xdg/2009-February/010191.html and
slightly edited)


Note that you could have, similarly, variables that are first in ram
only and then persisted to disk of the "state" (not
explicitly configured by the user) type.
Example: recently executed commands
(Same goes for data and cache)

Dieter