volatile config data and XDG Base Directory spec

[Simon McVittie]

On 18/02/14 23:53, Richard Hartmann wrote:
> this discussion has stalled yet again.

It has stalled because people aren't convinced that the extra category
is worthwhile.

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

                       DATA | CONFIG | STATE | CACHE | RUNTIME
sync across machines?  yes? | yes    | no    | no    | no
manage in VCS?         no   | yes    | no    | no    | no
should be backed up?   yes  | yes    | yes   | no    | no
can live in tmpfs?     no   | no     | no    | yes   | yes?
contains much data?    yes  | no     | no    | yes   | no

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

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.

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.

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

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.

    S