Re: Module proposal: dconf [migration from gconf]

[Sam Thursfield <ssssam gmail com>]

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.