mplayer (Message sign� : )

[Kevin Krammer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20121203/c49a8c34/attachment.pgp>