Re: Old gconf keys (was: Tab width)

On Thu, 2005-24-03 at 04:29 -0800, Karsten M. Self wrote:
>   - How do you prevent one application from modifying another app's
>     keys?  Don't think everything's going to play nice, particularly as
>     commercial apps start using GNOME infrastructure.  Does gconf have
>     an internal security model?  That accounts for different actions
>     _within a single user context_ being untrusted?

Whereas modifying another app's dot-file is impossible?

I've never had a problem with apps stepping on each other's toes
(probably because I use good apps), but if an app were to do so it could
do it just as easily with or without a registry.

>   - How do you manage shared key data (say:  proxy config data).

You put it in a standard location. GNOME already does this.

>   - How do you deal with apps parking obfuscated data in the registry?

As opposed to parking obfuscated data in dot-files?

>   - How do you deal with bloat (old settings, stale settings).  Treating
>     gconf as a write-only repository...leads to its own problems.
>     Messing up the cleanup process also has its downsides.

There are *no* pitfalls when messing with GConf. Just do a "gconftool
--dump" before and "gconftool --load" if you screw up. You can do it
while the app is still running and nothing will go wrong. And I already
posted an example of how one could write a trivial script to clean up
stale settings.

>   - How do you trivially make before-after comparisons, to see what an
>     installation or config change have done?

"gconftool --dump" + "diff"

>   - How do you clean up after something *does* eff-up a gconf file?

"gconftool --load"

Really, gconftool is great. Not only is gconftool great, but GConf uses
an open and fairly simple API, so you can write your own program to do
specific things to it.
   
> I'm not saying that gconf (and the Registry) don't have their benefits.
> But there are some serious costs, many of these *are* common to both
> gconf and the MS Windows Registry.  Naysaying doesn't make it otherwise.

Of the serious costs you've mentioned, none are serious and none are
costs above and beyond those of dot-files.

I'd argue that even your "comments for a group of options" gripe could
be easily solved by allowing documentation on GConf directories, which
shouldn't be all that complicated.

> > The problem is that Windows, with its shockingly poor implementation,
> > has given the entire concept a bad name.
> 
> No:  the concept has some fundamental problems.  Microsoft embraced the
> Registry in no small part because it's a vast pit of confusion from
> which Microsoft could establish and extend its criminal monopoly abuse.

As much as we all hate Microsoft, there comes a point when conspiracy
theory has to be thrown aside. They thought it would be good, and it
sucked.

I'd go as far as to say there are no *fundamental* problems with GConf
above and beyond the fundamental problems of a hierarchical filesystem.
There may be missing features -- it's still only a few years old, after
all -- but they're solvable.

But GConf *does* solve two nearly-fundamental problems with dot-files:

1. Each one uses a separate syntax.
2. Editing the dot-file doesn't modify the behaviour of already-running
applications.

...both of those problems *could* be solved, but it's not going to
happen.

-- 
Adam Hooper <[email protected]>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCQsyc90GtBxQ61zARAmOsAJwKEUUYsjq6OmZz3px262Gl9XPAHACcC6zU
Rn7LHv1x01RliVJvY6yR8cA=
=qiIc
-----END PGP SIGNATURE-----