volatile config data and XDG Base Directory spec

[Richard Hartmann]

On Wed, Feb 19, 2014 at 1:40 PM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:

> Looking at the table on
> <https://wiki.debian.org/XDGBaseDirectorySpecification>, which I'll
> reproduce here in its current state:

I looked over it myself and wasn't too happy with it.

If it's deemed a requirement to polish the distinctions before
debating the merit of $state (deliberately not implying a storage
location in this context) we can do so, but I think there's a
consensus on this ML what state entails so that may not be needed,
just now.

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


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

I would lean towards agreeing with Ryan: ~/.config is well-established
and mis-used already, anyway. Sticking with geeqie, take
.config/geeqie/history . The situation is similar to /etc .
Personally, I would choose $XDG_CONFIG_HOME/$0/state or
$XDG_STATE_HOME/$0/state with $XDG_STATE_HOME defaulting to
$XDG_CONFIG_HOME . It's not pretty, but it would be pragmatic,
fail-safe, and along established "best" practices.


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

Agreed.


> * "RUNTIME: can live in tmpfs" should be "yes": the specification for
>   XDG_RUNTIME_DIR is that it *is* transient. The implementation in
>   systemd, by the same author as that part of the specification, always
>   allocates your XDG_RUNTIME_DIR in a tmpfs. I believe Ubuntu has a
>   reimplementation of XDG_RUNTIME_DIR in the form of a PAM module;
>   I'm not sure whether it guarantees to use a tmpfs, or uses a fresh
>   subdirectory of /tmp, or what.

Agreed. Compare /run .


> XDG_RUNTIME_DIR is an "odd one out" in that specification: the others
> can all be set up correctly by unprivileged application code, but
> XDG_RUNTIME_DIR is more like an OS-provided API, and I don't think it
> can have its intended semantics without help from the OS.

$XDG_OS_RUNTIME_DIR , but that's done and in the past, so...


RIchard