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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
