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

[Dieter Plaetinck]

On Mon, 9 Feb 2009 02:10:33 +0200
Guillem Jover <guillem at hadrons.org> wrote:

> Hi!
> 
> On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote:
> > I see your points and they make sense.  I think the real issue is no
> > longer "is it configuration or not", but rather "is it configuration
> > that the user cares about or not"
> 
> I don't think that's the issue at hand. I believe mostly everyone
> cares about those settings getting somewhat preserved, but I don't
> think those settings are actually config, they are state.
> 
> Examples of this would be history (commands, URLs, visited tabs, etc),
> last window positions, last position in an editor or a document
> viewer, web cookies, previously filled web forms, etc.
> 
> So config would get restricted to settings one edits directly on a
> file, changes explicitly through a command line tool, or on a
> preferences or settings dialog in TUI or GUI apps.
> 
> And state fits just between config and cache, having properties of
> both, as state cannot be regenerated w/o user input (like config),
> but is not as important and it can be deleted or lost (like cache)
> and the apps will keep working as before, they might just require
> additional user interaction, and lots of GUI apps actually make this
> more or less visible as they have user selectable ways to clear state
> (for example clear history on a web browser). State is also a
> by-product of normal apps operation, in comparison to config which
> tends to be a "one" time thing.
Exactly, that's why it bothers me so much, all those state updates
making my "svn/git status" list longer then it should be, and which
forces me to fill my commit logs with mostly irrelevant changes (or
revert them each time)
> 
> I guess the biggest issue would be trying to come up with a proper
> definition for state.
> 
> regards,
> guillem



Actually I think your "state vs configs" splitup is a very similar
approach to my suggested "settings as configured by user/on behalf of
user versus settings on behalf of the application itself" splitup at
http://lists.freedesktop.org/archives/xdg/2009-January/010157.html


In practice, all settings that an app would like to store without
explicitly requested by the user can probably all be categorised under
state, so our ideas are very similar.

Your wording is probably better then mine, so a huge +1 from me for
adding a 4th concept 'state' to the current list of cache, configs and
data.

Dieter