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

[Guillem Jover]

Hi!

On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote:
> I'll tell you where I'm coming from: I'm having my $XDG_CONFIG_HOME
> under version control. The goal of this is to have all my "I want app
> foo to behave exactly like this" settings managed carefully.

I've a similar setup, and I additionally use it to sync my configs among
several systems, and for backup purposes.

> However, many applications store/update information irrelevant to me
> (last window size/position, last 10 opened items, etc) in there (often
> in the very same files),

On the other hand, I do care about this information, but it tends to
be host specific, so I don't usually want it to be propagated to a
different system, and currently do not keep it under vcs in preference
to having to deal with conflicts from the vcs. Although if it was
properly split I'd probably have a repo per host to keep it stored, or
one could use it to have a unified session on those different systems.

> 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.

I guess the biggest issue would be trying to come up with a proper
definition for state.

regards,
guillem