On Monday, 2012-12-03, David Nečas wrote: > I am in a similar situation, having things that may be created/edited by > users or the program, user-installed plug-ins and scripts that may be, > in fact, user-written plug-ins and scripts, arch-dependent modules and > data, files that are essentially run-time state but the user may want to > modify them manually, etc. After reading the specs a dozen times I > still have no idea what should go where. > > This attempts to provide some guidelines > > http://ploum.net/post/207-modify-your-application-to-use-xdg-folders > > but according to it the same file belongs to different places, depending > on how the user have come to its possession: If the user wrote a script > himself, he will be crying if it is deleted.
It's been a long time since I've read this, but how does it make any difference on how the file was obtained? Your plugins/scripts are not configuration, are they? So no matter if they have been manually written or downloaded they are still not configuration files. > So it must go to > XDG_DATA_HOME. But if exactly the same script is installed as an > extension it should go to XDG_CONFIG_HOME. So directories must be > duplicated between XDG_DATA_HOME and XDG_CONFIG_HOME. Which means > people will put their scripts to one or another randomly (you cannot > really stop them if both work) defeating the distinction. People will put files into the directory the application wants those files in. If your application's script directory is in XDG_DATA_HOME, then this is where people will put their script. I also fail to see how there would be any need to duplicate data. > What if the user installs an extension and, later, decides to modify it? > Does he have to move it from XDG_CONFIG_HOME to XDG_DATA_HOME because it > becomes valuable now? Why would it become more or less valuable depending on where it is stored? Are you somehow mixing the XDG_CACHE_HOME concept in here somehow? > Furthermore, if a file contains one value it is probably configuration. > If it contains a thousand it is probably data. And if it contains five > values? Six? A dozen? 16? 25? 41? 77? 118? 464? The size of the file or amount of its content will obviously have no impact on the location. If you consider a file a configuration file for your application then it is a configuration file for your application. Do you change the location or filename or your current setup when the size changes? > What if tools in the program remember their configuration? Losing the > parameter set for one tool would not make me cry, however, losing all of > them would. How likely is it that those two paths are on different media and one having a higher failure rate than the other? Most setups don't have $XDG_DATA_HOME or $XDG_CONFIG_HOME set so their defaults apply, meaning they are $HOME/.local/share and $HOME/.config respectively. Again, most setups have $HOME or even its parent directory on the same volume. Assuming you are currently storing your files somewhere below $HOME as well, why would your files become more likely to be lost? > Who am I to judge what the user will consider valuable data and what he > will consider just configuration? How do you judge that now? Or do you put all data into one single file? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
