Re: What constitutes user configuration files in the XDG basedir spec?
On Wed, 4 Mar 2009 22:17:43 +0100 Axel Liljencrantz liljencra...@gmail.com wrote: 2009/3/4 Dieter Plaetinck die...@plaetinck.be ... Imho that would fall in the config section, because the user configured the variables explicitly. Note that state vs config is not about persistent vs not-persistent. State and config (just like data, cache etc) are meant to categorize files. The fact that in your case your variables are first in memory and persisted to disk only later does not change their nature (which is config, imho) I didn't mean that the path the data takes while traveling to disk is what made it into state, I was strictly talking about the nature of the data stored. Another example. The next major fish release is planned to use universal variables to share a common command history between all running shells. Surely, that is state, not configuration? I believe it was even mentioned earlier in this discussion as an example of application state. Axel Yes indeed. that would be state :) Dieter ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
2009/3/5 Dieter Plaetinck die...@plaetinck.be On Wed, 4 Mar 2009 22:17:43 +0100 Axel Liljencrantz liljencra...@gmail.com wrote: ... I didn't mean that the path the data takes while traveling to disk is what made it into state, I was strictly talking about the nature of the data stored. Another example. The next major fish release is planned to use universal variables to share a common command history between all running shells. Surely, that is state, not configuration? I believe it was even mentioned earlier in this discussion as an example of application state. Axel Yes indeed. that would be state :) Which brings us to the question of where the backing store for universal variables should be stored if one where to separate configuration data from state. I'd say that it would better to store it with config data, because the implication of separating them to me would be that it is more ok to 'lose' state, e.g. maybe we don't back it up, etc.. It seems better to me to err on the side of causion then. Axel Dieter ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Wed, 4 Mar 2009 14:59:02 +0100 Axel Liljencrantz liljencra...@gmail.com wrote: 2009/3/2 Dieter Plaetinck die...@plaetinck.be It's always hard to define those things in words, but I think the wordings @ http://lists.freedesktop.org/archives/xdg/2009-February/010191.html are quite good. (and plenty of examples). I'm trying to hard to find the use cases where it may become blurry. I was thinking of an ftp client: if you store a recently visited ftp server it could be state, but it contains a password so you might call it data as well. OTOH if you think the password is that important you could make a bookmark and then it would be data, this is a good solution I think. Can you come up with examples where it might blur? I can. Fish, the shell I'm maintaining (regular command line shell, like bash) has a feature called universal variables, where you can set environment variables so that all your users fish instances on that machine will get the updated value at once. (Very useful for configuring your shell without forcing you to re-source your init file in every running shell or e.g. sharing ssh autentication between all your shells) The value is also saved to disk, so that it remains on reboot. The file used for storing these variables, is it state or configuration? As near as I can tell, environment variables are frequently used for storing both. Axel Imho that would fall in the config section, because the user configured the variables explicitly. Note that state vs config is not about persistent vs not-persistent. State and config (just like data, cache etc) are meant to categorize files. The fact that in your case your variables are first in memory and persisted to disk only later does not change their nature (which is config, imho) This also complies with Guillems definition (which was at the time probably more a draft but I think it works well) of config: - settings one edits directly on a file, - changes explicitly through a command line tool (your example) - changes explicitly on a preferences or settings dialog in TUI or GUI apps. ( taken from http://lists.freedesktop.org/archives/xdg/2009-February/010191.html and slightly edited) Note that you could have, similarly, variables that are first in ram only and then persisted to disk of the state (not explicitly configured by the user) type. Example: recently executed commands (Same goes for data and cache) Dieter ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Le mardi 24 février 2009, à 22:01 +0100, Axel Liljencrantz a écrit : 2009/2/9 Dieter Plaetinck die...@plaetinck.be Actually I think your state vs configs splitup is a very similar approach to my suggested settings as configured by user/on behalf of user versus settings on behalf of the application itself splitup at http://lists.freedesktop.org/archives/xdg/2009-January/010157.html In practice, all settings that an app would like to store without explicitly requested by the user can probably all be categorised under state, so our ideas are very similar. Your wording is probably better then mine, so a huge +1 from me for adding a 4th concept 'state' to the current list of cache, configs and data. Am I correct in interpreting the above discussion as in the consensus being that for now, what you refer to as state should be saved in the .config directory, and that a future xdg version may separate it into a third directory, perhaps to be named .state? I actually didn't feel there was consensus on this. My main worry is that I'm not sure it's worth the effort for app developers to do that, so this might not work. And I'm also not convinced that you have a clear line between state and config -- it will be blurry in quite some cases. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
2009/2/9 Dieter Plaetinck die...@plaetinck.be On Mon, 9 Feb 2009 02:10:33 +0200 Guillem Jover guil...@hadrons.org wrote: On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote: I guess the biggest issue would be trying to come up with a proper definition for state. regards, guillem Actually I think your state vs configs splitup is a very similar approach to my suggested settings as configured by user/on behalf of user versus settings on behalf of the application itself splitup at http://lists.freedesktop.org/archives/xdg/2009-January/010157.html In practice, all settings that an app would like to store without explicitly requested by the user can probably all be categorised under state, so our ideas are very similar. Your wording is probably better then mine, so a huge +1 from me for adding a 4th concept 'state' to the current list of cache, configs and data. Am I correct in interpreting the above discussion as in the consensus being that for now, what you refer to as state should be saved in the .config directory, and that a future xdg version may separate it into a third directory, perhaps to be named .state? If yes, could perhaps this be clarified in the standard? I just got a patch for a command line shell I am maintaining from a user who had written a patch to move the commandline history from .config to .cache. Axel ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Mon, 9 Feb 2009 02:10:33 +0200 Guillem Jover guil...@hadrons.org wrote: Hi! On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote: I see your points and they make sense. I think the real issue is no longer is it configuration or not, but rather is it configuration that the user cares about or not I don't think that's the issue at hand. I believe mostly everyone cares about those settings getting somewhat preserved, but I don't think those settings are actually config, they are state. Examples of this would be history (commands, URLs, visited tabs, etc), last window positions, last position in an editor or a document viewer, web cookies, previously filled web forms, etc. So config would get restricted to settings one edits directly on a file, changes explicitly through a command line tool, or on a preferences or settings dialog in TUI or GUI apps. And state fits just between config and cache, having properties of both, as state cannot be regenerated w/o user input (like config), but is not as important and it can be deleted or lost (like cache) and the apps will keep working as before, they might just require additional user interaction, and lots of GUI apps actually make this more or less visible as they have user selectable ways to clear state (for example clear history on a web browser). State is also a by-product of normal apps operation, in comparison to config which tends to be a one time thing. Exactly, that's why it bothers me so much, all those state updates making my svn/git status list longer then it should be, and which forces me to fill my commit logs with mostly irrelevant changes (or revert them each time) I guess the biggest issue would be trying to come up with a proper definition for state. regards, guillem Actually I think your state vs configs splitup is a very similar approach to my suggested settings as configured by user/on behalf of user versus settings on behalf of the application itself splitup at http://lists.freedesktop.org/archives/xdg/2009-January/010157.html In practice, all settings that an app would like to store without explicitly requested by the user can probably all be categorised under state, so our ideas are very similar. Your wording is probably better then mine, so a huge +1 from me for adding a 4th concept 'state' to the current list of cache, configs and data. Dieter ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Hi! On Thu, 2009-01-15 at 22:10:25 +0100, Dieter Plaetinck wrote: I'll tell you where I'm coming from: I'm having my $XDG_CONFIG_HOME under version control. The goal of this is to have all my I want app foo to behave exactly like this settings managed carefully. I've a similar setup, and I additionally use it to sync my configs among several systems, and for backup purposes. However, many applications store/update information irrelevant to me (last window size/position, last 10 opened items, etc) in there (often in the very same files), On the other hand, I do care about this information, but it tends to be host specific, so I don't usually want it to be propagated to a different system, and currently do not keep it under vcs in preference to having to deal with conflicts from the vcs. Although if it was properly split I'd probably have a repo per host to keep it stored, or one could use it to have a unified session on those different systems. I see your points and they make sense. I think the real issue is no longer is it configuration or not, but rather is it configuration that the user cares about or not I don't think that's the issue at hand. I believe mostly everyone cares about those settings getting somewhat preserved, but I don't think those settings are actually config, they are state. Examples of this would be history (commands, URLs, visited tabs, etc), last window positions, last position in an editor or a document viewer, web cookies, previously filled web forms, etc. So config would get restricted to settings one edits directly on a file, changes explicitly through a command line tool, or on a preferences or settings dialog in TUI or GUI apps. And state fits just between config and cache, having properties of both, as state cannot be regenerated w/o user input (like config), but is not as important and it can be deleted or lost (like cache) and the apps will keep working as before, they might just require additional user interaction, and lots of GUI apps actually make this more or less visible as they have user selectable ways to clear state (for example clear history on a web browser). State is also a by-product of normal apps operation, in comparison to config which tends to be a one time thing. I guess the biggest issue would be trying to come up with a proper definition for state. regards, guillem ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Le jeudi 15 janvier 2009, à 22:10 +0100, Dieter Plaetinck a écrit :
I see your points and they make sense. I think the real issue is no
longer is it configuration or not, but rather is it configuration
that the user cares about or not
This definition won't work. And this thread can show you why: you don't
care about your window position/size, but other people do.
Maybe we can keep everyone happy if we make the spec specify more then
one config file per app inside $XDG_CONFIG_{HOME,DIRS}
Hrm. I don't get it. The specification explicitly mentions
subdirectories, so applications definitely can use more than one config
file.
Vincent
--
Les gens heureux ne sont pas pressés.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Le mercredi 14 janvier 2009, à 21:23 +0100, Dieter Plaetinck a écrit : Rodney Dawes wrote: If I resize my app's window to be more suitable for my uses, where should that configuration be saved then? It is configuration data, though all configuration data may not necessarily be what you expect it to be. It is not *user configuration*. Your program comes up with that by itself, your user probably doesn't even know about this. Err, if the user resizes the window, I would think he knows that, well, he resizes the window. Am I missing something here? :-) I'd think it's some user configuration too. Not critical, but still. [...] I hereby propose a draft of an updated version of the spec: http://users.edpnet.be/dieter/basedir-spec-0.7-PROPOSAL.html What I did is just add a section examples which describes a bit more in detail what belongs where and gives some practical examples. I like the idea of giving examples. I kind of disagree with These files are only to be edited by the user manually, or by the relevant program on behalf of a user because the user changed configuration through a GUI:, though. What do other people think? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thursday 15 January 2009, Vincent Untz wrote: I kind of disagree with These files are only to be edited by the user manually, or by the relevant program on behalf of a user because the user changed configuration through a GUI:, though. Yes I disagree with this. Config files are used for much more than this, and I don't see a problem with that. Config files are the best place to store window size, toolbar positions, recent urls, etc. etc. -- David Faure, fa...@kde.org, sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
David Faure wrote: Yes I disagree with this. Config files are used for much more than this, and I don't see a problem with that. Config files are the best place to store window size, toolbar positions, recent urls, etc. etc. +1 Rodney Dawes wrote: It is not *user configuration*. Your program comes up with that by itself, your user probably doesn't even know about this. I'm not sure how window size got related with $XDG_CACHE_HOME? Just because program generates them? With this, what about created icons on desktop via GUI dialog? Implying previous, they are also non essential and should go with $XDG_CACHE_HOME, just because program generated them. IMHO all files used for some kind of configuration/re-configuration, either by user or by program itself, should go on the same place and that place is already defined. -- Sanel Zukan http://equinox-project.org ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thursday 15 January 2009, Sanel Zukan wrote: Implying previous, they are also non essential and should go with $XDG_CACHE_HOME, just because program generated them. No. A cache is something that can be deleted without bad side effects. -- David Faure, fa...@kde.org, sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 1:48 PM, David Faure dfa...@trolltech.com wrote: On Thursday 15 January 2009, Sanel Zukan wrote: Implying previous, they are also non essential and should go with $XDG_CACHE_HOME, just because program generated them. No. A cache is something that can be deleted without bad side effects. Not at all. It's something that can be recreated, possibly taking a lot of resources, not something unneeded. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 2:49 PM, David Faure dfa...@trolltech.com wrote: On Thursday 15 January 2009, Patryk Zawadzki wrote: Not at all. It's something that can be recreated, possibly taking a lot of resources, not something unneeded. Yes, that's exactly what I meant. Therefore, desktop icons and window size and other settings indirectly changed by the user do NOT belong there. That's _exactly_ why they belong there :). There is no way a _computer_ can recreate such data on its own by means of any calculations. What constitutes a cache to me is a pile of data that could be recreated by the program if needed but keeping it around requires significantly less resources. Think temporary internet files or podcasts or your music collection's ID3 tag database or even a list of first 123456 prime numbers. Following your rationale I could argue that your spreadsheets and Word document should be kept in cache as the *user* is perfectly capable od recreating the data. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thursday 15 January 2009, Patryk Zawadzki wrote: On Thu, Jan 15, 2009 at 2:49 PM, David Faure dfa...@trolltech.com wrote: On Thursday 15 January 2009, Patryk Zawadzki wrote: Not at all. It's something that can be recreated, possibly taking a lot of resources, not something unneeded. Yes, that's exactly what I meant. Therefore, desktop icons and window size and other settings indirectly changed by the user do NOT belong there. That's _exactly_ why they belong there :). There is no way a _computer_ can recreate such data on its own by means of any calculations. Misunderstand on what there is about, I think? I meant such things do NOT belong in cache, they belong in config. I think you meant that too? What constitutes a cache to me is a pile of data that could be recreated by the program if needed but keeping it around requires significantly less resources. Think temporary internet files or podcasts or your music collection's ID3 tag database or even a list of first 123456 prime numbers. I totally agree. Following your rationale I could argue that your spreadsheets and Word document should be kept in cache as the *user* is perfectly capable od recreating the data. This is certainly not what I said nor implied. I think we agree, but we both sent ambiguous enough emails to misunderstand each other :-) -- David Faure, fa...@kde.org, sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 3:53 PM, David Faure dfa...@trolltech.com wrote: I think we agree, but we both sent ambiguous enough emails to misunderstand each other :-) You are of course 100% right. I misread the quotes in earlier emails and thought you were one to imply window size is not config :) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Patryk Zawadzki wrote:
On Thu, Jan 15, 2009 at 3:53 PM, David Faure dfa...@trolltech.com wrote:
I think we agree, but we both sent ambiguous enough emails to misunderstand
each other :-)
You are of course 100% right. I misread the quotes in earlier emails
and thought you were one to imply window size is not config :)
Thanks for the replies everyone.
I'll tell you where I'm coming from: I'm having my $XDG_CONFIG_HOME
under version control.
The goal of this is to have all my I want app foo to behave exactly
like this settings managed carefully.
However, many applications store/update information irrelevant to me
(last window size/position, last 10 opened items, etc) in there (often
in the very same files),
which causes those config files to be no longer in sync and require a
commit (with changes I don't care about) or a revert (ugly, because it's
very hard to programmatically know if it's safe to revert or not, there
could be other chances in the file who *are* relevant),
and you can't ignore a particular section or a specific xml element of a
config file with any VCS, afaik.
I see your points and they make sense. I think the real issue is no
longer is it configuration or not, but rather is it configuration
that the user cares about or not
Maybe we can keep everyone happy if we make the spec specify more then
one config file per app inside $XDG_CONFIG_{HOME,DIRS}
One such config file would contain all settings explicitly configured by
the user (or application on behalf of the user), while the other config
file would store the configs that the application wants to store on it's
own behalf.
This ways user can manage/ignore with more granularity. At the very
least, this would cause a bit better overview (vs all settings
regardless of their nature in 1 file).
You could even take it a step further and specify naming conventions for
some known types of configuration (eg:
$XDG_CONFIG_DIR/myapp/{windowinfo,lastviewed,...}. Just thinking out
loud here.
Thanks,
Dieter.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Rodney Dawes wrote:
On Sat, 2009-01-10 at 22:09 +0100, Dieter Plaetinck wrote:
Hi all,
at http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
it is explained that $XDG_DATA_{HOME,DIRS} is for (user specific) data
files and $XDG_CONFIG_{HOME,DIRS} for (user specific) configuration
files.
However, it is not exactly explained what each mean.
Specifically, afaik everything that goes into $XDG_CONFIG_HOME should be
controlled by the user himself, eg any update of files in this directory
is the result of:
- the user updating the file himself manually.
- the file being updated because the user changed one or more settings
in a GUI panel.
Eg: Isn't it wrong for software to update files in $XDG_CONFIG_HOME (and
by extension $XDG_CONFIG_DIRS) around the users back?
I've seen many programs who store things like last window position,
last 10 opened items etc in $XDG_CONFIG_HOME. I don't think this is
what $XDG_CONFIG_HOME is for (I think this belongs in the user data
category), but then again, I couldn't find this being defined in the spec.
Do you agree with this point of view?
If so, I would be happy to contribute an updated version of the spec
based on the above wordings.
If I resize my app's window to be more suitable for my uses, where
should that configuration be saved then? It is configuration data,
though all configuration data may not necessarily be what you expect
it to be.
It is not *user configuration*. Your program comes up with that by
itself, your user probably doesn't even know about this.
Imho, the best match is user specific non-essential data files, hence
$XDG_CACHE_HOME.
I hereby propose a draft of an updated version of the spec:
http://users.edpnet.be/dieter/basedir-spec-0.7-PROPOSAL.html
What I did is just add a section examples which describes a bit more
in detail what belongs where and gives some practical examples.
It's based on what I could find in previous posts on this mailing list
and -obviously - largely on my own interpretation, so I would like to
hear opinions about this and maybe start a discussion.
Either way, I think the current spec is a bit too unclear and could
really use some practical examples as guidance for application developers.
Dieter
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Sat, 2009-01-10 at 22:09 +0100, Dieter Plaetinck wrote:
Hi all,
at http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
it is explained that $XDG_DATA_{HOME,DIRS} is for (user specific) data
files and $XDG_CONFIG_{HOME,DIRS} for (user specific) configuration
files.
However, it is not exactly explained what each mean.
Specifically, afaik everything that goes into $XDG_CONFIG_HOME should be
controlled by the user himself, eg any update of files in this directory
is the result of:
- the user updating the file himself manually.
- the file being updated because the user changed one or more settings
in a GUI panel.
Eg: Isn't it wrong for software to update files in $XDG_CONFIG_HOME (and
by extension $XDG_CONFIG_DIRS) around the users back?
I've seen many programs who store things like last window position,
last 10 opened items etc in $XDG_CONFIG_HOME. I don't think this is
what $XDG_CONFIG_HOME is for (I think this belongs in the user data
category), but then again, I couldn't find this being defined in the spec.
Do you agree with this point of view?
If so, I would be happy to contribute an updated version of the spec
based on the above wordings.
If I resize my app's window to be more suitable for my uses, where
should that configuration be saved then? It is configuration data,
though all configuration data may not necessarily be what you expect
it to be.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
