Re: Module proposal: dconf [migration from gconf]

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.

 .''`.      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?=

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]