Re: Module proposal: dconf [migration from gconf]

[Alexander Larsson <alexl redhat com>]

On Thu, 2009-10-22 at 14:23 +0100, Sam Thursfield wrote:
> On Thu, Oct 22, 2009 at 1:48 PM, Alexander Larsson <alexl redhat com> wrote:
> > 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.
> >
> [snip]
> >
> > 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.
> 
> From "helper functions to migrate chunks of the tree in a simple
> fashion, maybe with a simple description of how to convert some
> keynames" it wouldn't be a big step to create a seperate tool to
> import key data into dconf, which would read an application-provided
> "map" on 'make install' or package postinstall and do the conversion
> then.

This requires all conversion to be specifyable with simple mappings,
rather than more generic code, which is not always the case with complex
configuration. Furthermore, doing this at install time is not possible,
as you might need to convert users settings that are not even accessible
(i.e. using non-mounted NFS homedirs or whatnot).

However, it would be possible to have such a tool that can be spawned by
the app when the user runs it to do the conversion. Not sure if its
better than accessing gconf via a GSettings API though.