Re: RFC GnomeGoal #3

[Shaun McCance <shaunm gnome org>]

On Mon, 2006-08-14 at 12:37 -0400, Germ�Po�ama�rote:
> On Mon, 2006-08-14 at 11:18 -0500, Federico Mena Quintero wrote:
> > On Sat, 2006-08-12 at 12:00 +0100, Ross Burton wrote:
> > 
> > > libgconf-bridge doesn't handle per-machine state yet, but it will handle
> > > multiple windows just fine: you give it a gconf path prefix to persist
> > > the states at, so for different windows the program can generate
> > > different prefixes.
> > 
> > Interesting!  Great to have working code.  Can you please add a link to
> > it to the wiki?
> > 
> > 	http://live.gnome.org/GnomeGoals/SaveState
> > 
> > I've added an important requirement:  we need to be able to purge old
> > keys when they are no longer needed.  We need apps to be able to say, "I
> > no longer care about this window's state; please erase whatever you may
> > have put into GConf".
> 
> IMHO, it could be better the opposite approach: "I do care only about
> these group of keys, please GConf/Whatever delete everything else in my
> application keys".
> 
> The rationale is I don't know which keys were deprecated 'n' versions
> ago I don't know how polluted could be the user preferences between each
> upgrade/install/deinstall. But, I do know what are the active current
> keys and the previous versiones (which I'm deprecating with the new
> version).

Insanity.  So I'll use a machine that has 2.20 installed, and
since 2.20 no longer uses certain keys, it just drops the data
from the keys from GConf.  And then I'll use another machine
that still has 2.18, and its state is gone.

I mean, I understand that occasionally compatibility issues
happen, but why would we intentionally set out to create them?

--
Shaun