Le jeudi 22 octobre 2009 à 14:48 +0200, Alexander Larsson a écrit : > 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. That, I agree with. GConf in its current state is extremely reliable, we probably don’t want to lessen that reliability. > 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. That means keeping on maintaining GConf for quite a long time. For the record, it took us around 8 years to get rid of GTK+ 1.2. GConf is not as widespread, but it is already ~600 packages. From the moment GSettings is widely deployed, I’d expect at least 3-4 years before being able to not install it by default on Linux systems; in the meantime, this means starting both daemons in user serssions. And 5-6 years before being able to get completely rid of it. This plan is clearly less work right now, but it means more maintenance work in the long term. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=