mplayer (Message sign� : )
krammer at kde.org
Mon Dec 3 02:08:10 PST 2012
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
> 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
> 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
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?
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the xdg