volatile config data and XDG Base Directory spec

[Thomas Koch]

Hi,

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.

User Story:

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

------

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

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

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

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 
request?

Regards, Thomas Koch