volatile config data and XDG Base Directory spec
krammer at kde.org
Wed Feb 19 09:51:16 PST 2014
On Wednesday, 2014-02-19, 17:42:37, Richard Hartmann wrote:
> On Wed, Feb 19, 2014 at 1:40 PM, Simon McVittie
> > But
> > surely if it's small, it doesn't matter if it gets sync'd across
> > machines unnecessarily? If an application wants to store explicitly
> > per-machine state, it can use the D-Bus/systemd machine ID as a key,
> > like GNOME does for display settings (I know that's config rather than
> > state, but the principle is the same).
> Thanks for this; it highlights precisely why state is needed.
> This is not about storage size, it is about churn in configuration files.
> Looking at, e.g., geeqie, there's a section called <layout> in
> geeqierc.xml. This contains window size, last path, and a plethora of
> stuff configuration management does not care about.
> Assuming you put your configuration under proper version control, this
> state information changes all the time. It is not something you want
> to sync between machines for several reasons. You are synching state
> information which may be invalid (lastpath), non-applicable (desktop
> resolution settings on a netbook), or outright harmful (this directory
> is not needed any more). Additionally, you are filling your VCS
> history with random noise, making tracking the actual changes harder.
> This results in broken workflows, manual rewriting/pruning of state,
> or outright breakage.
> And _that_ is why Thomas, me, and others consider carrying state in
> configuration such an issue.
So it is mostly about developers using the same file for config and state
instead of using a separete state file?
If it where in a different file, even in the same location, then only the
actual config file would be tracked by the VCS and the state files would not.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the xdg