volatile config data and XDG Base Directory spec
thomas at koch.ro
Sat Feb 22 13:14:50 PST 2014
I'm happy that the discussion could be revived although the thread drifted a
bit away from the STATE topic.
Maybe it helps to describe a /persona/ for my /user story/:
Axel is an experienced linux power user, working in a team of web developers
and running his own private mail-, file- and web-server. Besides his own
laptop, company laptop, company workstation, several virtual machines he also
administrates the linux laptops of his wife and parents.
Axel uses ZSH, Emacs, tmux, Firefox, Kmail, Awesome Window Manager and Gnome
Classic on Debian. He synchronizes his configuration files with Git (helped by
vcsh) over several machines.
Axel wants to be sure, that he tracks all important configuration inside his
$HOME with Git. He does not want to be distracted by files that are not
configuration or that change with every execution of a program or that are
specific to a machine (like window positions, command line history, recently
It might sound as if the described persona is a minor group of the total linux
user base and could be ignored. On the other hand, once things become possible
for the linux power user, we tend to develop tools that deliver the same
advantages (sync of config) to the rest of the user base.
On Wednesday, February 19, 2014 01:40:39 PM Simon McVittie wrote:
> On 18/02/14 23:53, Richard Hartmann wrote:
> the difference between DATA and STATE appears to be "STATE doesn't
> contain much data, and doesn't need to be sync'd across machines". 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).
Well, you're pinpointing it. Syncing window positions or recently opened files
across machines would lead to undesired behaviour because different machines
have different screen setups and differnt sets of files. You put the burden on
the application developer to distinguish between machines, but that's
unrealistic. The xdg-basedir-spec should rather help by providing a directory
for state information that makes sense only in the context of this machine.
> I agree that storing state in ~/.config is a bug, but I think that's a
> misuse of existing categories rather than a need for a new category -
> why wouldn't ~/.local/share be OK? - and I don't think adding new
> categories is going to reduce developer confusion/misuse between
Using .local/share instead of .config for STATE data would be an improvement.
But since others already raised concerns, it seems that we need a third
category between DATA and CONFIG: STATE.
> Other things I'm not sure are right in that table (I'm deliberately not
> editing the wiki page without some sort of consensus):
> * "CACHE: can live in tmpfs" somewhat defeats the point of a cache:
> it's a trade-off between "it might be expensive to download or
> regenerate this later" (for a very general definition of
> "expensive"), and "I can always download or regenerate it later if I
> need to". It *can* go in a tmpfs if statelessness is specifically
> considered more valuable than bandwidth/CPU/time, but that shouldn't
> happen by default.
It's not that important to me whether .cache is in tmpfs or not. But since I
reboot my laptop only once in a month it's ok for me to loose firefox caches,
.thumbnails and a-likes in those cases.
Back to STATE: Yes, it's hard already with the existing categories to get
projects to conform. But I believe that the spec is short on examples and
explanations. This thread and the Debian wiki page already contain some
helpful hints that might be worth to be included in a next version of the
I also don't have much hope that the long tail of applications will conform to
the spec at any point in time. But I believe that at least libraries will
quickly introduce a STATE directory once it's included in the standard. And
when KDE and Gnome libraries use a separate STATE folder, then we already gain
Is there any formal process for the development of the xdg specs? I found the
Git repo and bugtracker today and could open an issue for the STATE DIR
Regards, Thomas Koch
More information about the xdg