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