On Thu, 22 Aug 2013 08:27:21 -0700 Thomas Kluyver <[email protected]> wrote:
> On Aug 22, 2013 6:17 AM, "Dieter Plaetinck" <[email protected]> wrote: > > > > On Tue, 13 Aug 2013 14:05:08 +0100 > > Jerome Leclanche <[email protected]> wrote: > > > > > On Tue, Aug 13, 2013 at 9:11 AM, Thomas Koch <[email protected]> wrote: > > > > > > > On Tuesday, December 04, 2012 04:35:12 PM Thomas Koch wrote: > > > > > Some applications store "volatile" config data or "convenience data" > > > > like: > > > > > > > > > > - last window position > > > > > - recently opened file > > > > > - last time application was run > > > > > - ... you name it > > > > > > > > > > Most annoyingly these applications create config files on first run > even > > > > if > > > > > I won't ever run those apps again! So my home folder accumulates > many > > > > > worthless config files. > > > > > > > > > > There are many examples of this in the .kde folder. > > > > > > > > > > I don't like to really call this data "configuration". It's not > > > > > intentionally set by the user. It has lot less value than "real hand > > > > > crafted configuration" (think .vimrc, .emacs, .zsh, .gnupg/gpg.conf, > > > > > .ssh/config). > > > > > > > > > > Do you have an idea for a name for such transient settings? Maybe > > > > "state"? > > > > > > > > > > I'd really like to have an additional category besides CACHE, DATA, > > > > CONFIG > > > > > for this kind of settings. Having config and state mixed is mostly > > > > > annoying if > > > > > > > > > > - one keeps config in a VCS (git), > > > > > - an application isn't used anymore but the state data remains > > > > > - configuration is somehow managed centrally and the application > doesn't > > > > > read configuration from /etc > > > > > > > > We've had this discussion again at Debconf[1] and discovered that > several > > > > people reported this issue on different channels. We agreed that it > would > > > > make > > > > sense to add a third category STATE which goes into a place of its > own. > > > > > > > > We don't think that STATE is the same as CACHE. The "backup test" is > not a > > > > good indicator. I could live with loosing the state data in an > accident. > > > > But I > > > > keep my .cache folder in a tmpfs so that it does not persist across > > > > reboots. I > > > > would not like my STATE data to go away with every reboot. > > > > > > > > > > Realistically, that's not feasible. The basedir spec is having a hard > > > enough time being adopted as it is. Say we introduce XDG_STATE_HOME: > > > - Plenty of apps still create config files on first run, because that's > > > just what they do. > > > - One more dotdir for $HOME, at very little benefit. > > > - More confusion for developers who want to use the basedir spec. "Does > > > this count as state?" is a question they now have to ask themselves for > > > every single setting. > > > - Most GUI apps use their toolkit's Settings class. State would have to > > > either be managed separately or be implemented within the toolkit and > > > specified declaratively somehow. Apart from window geometry, nearly > none of > > > it would be handled automatically; for the rest it would just be more > work. > > > -> At this point, you're better off saving window geometry state in > your > > > WM config. > > > -> Falling short, there are ways to manage and clean ~/.config > > > programmatically; that's one of the big bonuses of having this spec. > > > > > > I've been a big evangelist of the basedir spec and I'm more often than > not > > > met with developers who (understandably) flat out refuse to split their > > > config file into a dir, or multiple dirs ("cache is not config", ...). > If > > > on top of that you start telling them "But this type of config goes > here!", > > > they'll laugh at you. > > > > > > I think the xdg basedir spec has good ideals, and sure, it can take some > work to adopt it properly. But this subject comes up often enough to say > it should be dealt with properly. > > Having a spec that takes care of config, data, cache but not state (at > least not in a proper way) makes the spec incomplete and what's the point > of that? > > Keeping the spec 3/4-complete as a "favor" to developers who are short on > time/interest seems lame; I would rather finish the spec and if devs don't > feel like implementing it all the way, they should at least accept patches > from people who do. > > > > But who's to say there are only 4 categories? I'm sure we could come up > with 5, 6, or more quite easily. There are all kinds of ways to distinguish > different data. The emphasis should be on what is useful for devs and > users, not on matching some mental model of different kinds of data. And > part of being useful is getting devs to adopt it. An imperfect but widely > used standard beats a perfect standard that half the devs ignore any time. > > I'm not saying adding a fourth category is wrong, but I think it should be > justified in terms of practical value and chances of adoption, not just on > theoretical grounds. > I agree, but the proposal for a 4th state category comes up often enough; i haven't seen anyone advocating a 5th or 6th category. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
