Re: Module proposal: dconf [migration from gconf]

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-10-16 at 17:29 +0200, Josselin Mouette wrote:
> Le mardi 13 octobre 2009 à 13:12 +0200, Vincent Untz a écrit : 
> > Ryan is a bit sad to not get feedback on his proposal, so a bit more
> > seriously: I think what we probably need is a migration plan. Should we
> > move all the code from gconf to dconf in one cycle (if possible)? Should
> > apps implement migration for the data in gconf? etc.
> 
> There are a few traps that would be nice to avoid during the migration
> from GConf to GSettings: 
>       * keeping GConf as it is now - there are ~500 applications using
>         GConf out there, not porting GConf means keeping it forever ; 
>       * having the user lose his settings and set up things again ; 
>       * having the developer of each application add migration code.
> 
> Therefore a possible, sane transition plan looks like the following. 
>      1. A new, source-compatible (if possible binary-compatible, but
>         that’s less critical) GConf library is written on top of
>         GSettings. All applications using GConf start using it
>         together. 
>      2. A migration tool is written to convert GConf data to dconf
>         data. 
>      3. This tool is used by distributors to make GConf schemas and
>         system defaults available to dconf. (How it is done completely
>         depends on the distribution.) 
>      4. The tool is launched once by gnome-session. 
>      5. An interface is provided so that an application can be ported
>         from GConf to GSettings while still seeing the old data. To
>         achieve that, either the data is not moved at all, or the API
>         can specify an “old” location in GConf format as well as a “new”
>         location in GSettings format.

I don't like this idea much. Here is how I see things:

There are two kinds of apps, those that use the gsettings API (and these
should also avoid linking to gconf libs) and those that use the gconf
API. Ideally we would like everyone to move to the GSettings API, but
that will not be 100% done in a long while. However, we can work hard to
at least do so for the core desktop apps such that e.g. login speed is
not restricted by blocking on gconfd serialization.

Now, for an application using the gconf API I don't see any benefit
whatsoever of changing where the data for this is stored to be in dconf.
On the contrary, such a shim is a lot of work and will have lots of bugs
that break previously working code. To no obvious gain for end-users.
So, I say, leave old apps using gconf alone, and leave the gconf storage
alone too. It works (to some degree) and will continue to work (to the
same degree) in the future with minimal maintainance.

The focus should be on converting apps to use the gsettings api, which
gives us multiple advantages:
* No gconf/orbit dependency
* Better performance
* A nicer API and type system for data storage
* A chance to redo our apps configuration setup, cleaning up old
  mistakes in keynames, key structure, backwards compat keys, etc.

However, at the same time its crucial that we allow a seamless migration
path for users preferences. I don't think we ever want to do a fully
automated migration from gconf to dconf, because we'd lose the ability
to clean up stuff, and because i'm sure there are weird uses of gconf
that will be hard to map. So, I think we need to do a one-time
per-application code to migrate from gconf to dconf.

We don't want to have to force the new applications to link to gconf
just for migration though, since that leaves us with a dependency which
we want to get rid off. So, what we need is a dynamic (i.e. a module
loaded only when required, typically when the app detects that some
is_migrated dconf key is not set) read-only GSettings implementation
that reads from gconf (in some robust and simple, but not necessarily
extremely efficient way). 

We want to both be able to read all keys as per the current user, and
determine whether a gconf key really has been set or if it has inherited
the default value (so we don't force all the defaults to be set in the
new dconf store). Also, we should probably have some helper functions to
migrate chunks of the tree in a simple fashion, maybe with a simple
description of how to convert some keynames. This could be shipped in
the GSettings API if its generic enough, or otherwise as a small
cut-and-pasted module.