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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg