getting app developers to separate user config and app state info

Dieter Plaetinck dieter at plaetinck.be
Fri Apr 8 09:47:39 CEST 2011


On Thu, 7 Apr 2011 23:42:26 +0200
Richard Hartmann <richih.mailinglist at gmail.com> wrote:

> On Thu, Apr 7, 2011 at 22:40, Dieter Plaetinck <dieter at plaetinck.be>
> wrote:
> 
> > Me too.  But I got kinda demotivated after my previous attempts to
> > get it going failed. Feel free to give it another go, you have my
> > full support.
> 
> Who else is in favour of this? Do we want to hammer out a full
> proposal on this list, first?
> 
> Dieter, can you send any and all suggestions, planning and
> brainstorming to me/this list so we have it in one place?

I think all my ideas are in the `What constitutes "user configuration
files" in the XDG basedir spec?` thread, but I think that thread spans
several months, is there a good archive reader to see the entire thread? If so, start reading that :)
I have some more notes at home, if anyone knows how I can easily
re-read the entire thread I'll check my notes and see if anything
should be added.

But basically, IIRC I think it comes down to:
* separation of data and config can be blurry and some people have
  different definitions (but this is not necessarily a problem
  because...
* ..there is a clear difference between 1) config as explicitly
  configured by user (by writing a text file or changing options in 
 preferences settings from inside the app), and 2) config/data/state as
 automatically saved by the application.
What I care mostly about, is that 1) and 2) go into separate files.
IIRC we discussed in my fd.o thread at length whether 2) is config or
data, but never reached a conclusion, so I would say don't aim to
categorize it as config/data, just get app devs to store it in a
separate file, either in $XDG_CONFIG_HOME or $XDG_DATA_HOME.

We should also think a bit about whether this separation would suffice.
We obviously want the full 1) in a VCS (I don't see a problem with 1),
but 2) is probably something we don't to version, but we might want to
back it up (in host-specific backups).  but do we sometimes want to
synchronize it to other hosts? that might warrant version controlling it
again. But then we'd use something like dvcs-autosync where we care
less about single commits, clean history etc, and just use the vcs as
syncing method.  But what happens when you only want to synchronize
specific aspects? To take the claws-mail example, I might want to
synchronize "which email account had I last open" info, but not
"what was the last window position" (both are automatically saved by
the app and would go in the same file). OTOH this last point sounds like
YAGNI so maybe it would be just fine to not synchronize 2 at all. (just
back it up per-host)


Dieter


More information about the vcs-home mailing list