Re: [G2R] Re: PATCH for some random stuff.

[Bruce Robert Pocock <brpocock 10east com>]

On Thu, 2002-06-27 at 05:07, Michael Meeks wrote:
> 
> On Wed, 2002-06-26 at 17:19, Bruce Robert Pocock wrote:
> > Devil's Advocate: Would this be an issue in cases of e.g. one user, two
> > machines, where the preference might be active on one machine but
> > archaic on the other? That's the Microsoft explanation for the Windows
> > policy of "never delete from the Registry..."
> 
> 	If there is no gconf value related to the key gconf returns false, 0,
> ... so it seems there is no problem to me.
> 

Actually, I was thinking of the more general case - those nonexistent
"hard core bin-compat guidelines," i.e. the policy on removals in
general:

For example, suppose I have two workstations sharing a gconf database
(be it a shared homedir or some future ACAP link or similar); then, I
may have e.g. Nautilus for GNOME 2.0 and Nautilus for GNOME 3.0 on two
different machines, both of which I use. In that case, I'd want to keep
around both sets of configuration data.

On the other hand, for that 90%+ of users[1] who just have a single
workstation, it might make perfect sense to delete the "old" preferences
when the upgrade is performed.

As a (rather extreme) example, I've seen .gimp folders floating around
with enormous tempfiles rotting away because the user upgraded and
didn't know about the "hidden" prefs folder. I doubt we'll want to store
Mbytes of data in gconf in the near future, but having seen NTUSER.DAT
files into the 100's of MB, I'm a *little* concerned about what kind of
policy there might be.

As a suggestion: Since it takes a certain amount of sysadmin effort to
create a shared gconf - whether by nfs:/home, or some other future
technology - it might be legitimate to put in a (non-end-user-visible)
gconf key to the effect of: "don't remove old configuration data without
asking the user first;" thus the 90% are protected, and the 10%, who we
may assume to have either greater technical savvy, or access to a tool
which should do this for them (e.g. hypothetical "set-up-gnome-acap"),
could still keep from destroying their existing preferences if they need
to.



[1] although I suspect the ratio is changing as GNOME enters more
schools and businesses who like to share homedirs from nice,
easy-to-back-up fileservers...