Module proposal: dconf

[Ryan Lortie]

Hello

dconf is a very conceptually simple key/value storage system with an
implementation that makes it extremely efficient.  There have been 3
tarball releases so far: 0.1, 0.1.1, 0.2.  More will be following in the
coming weeks and months.


I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop
release set.


dconf brings in no new external dependencies [except, see below about
glib].  There is also a separate module, 'dconf-editor', however, that
uses Vala.  I have already proposed Vala as an external dependency for
2.30 in a separate mail -- I think the recent advances in the stability
of that project make this an extremely reasonable thing to do (even
regardless of dconf).

dconf is available for download from download.gnome.org, has its main
webpage on live.gnome.org, is under version control in git.gnome.org,
uses bugzilla.gnome.org for bug tracking and will soon have its gtk-doc
published at library.gnome.org.  This email is inspired by
vuntz@....

Adoption is not wide among GNOME projects at this point, but hopefully
that changes soon.  There is also not very much community involvement at
this point aside from a somewhat successful Summer of Code project.  All
development, however, has been openly discussed and done entirely in the
open from the beginning.

dconf is very "GNOME 3.0 ready".  Not only does it avoid the use of
deprecated libraries -- it removes a big one; gconf using ORBit.

The license is LGPL 2.1 "or later" for libraries and binaries (since you
never know when code from a binary will want to make its way into a
library).

The main technical blocker on the inclusion of dconf is that it relies
on a branch of glib that has not yet been merged to master.  We have had
a discussion at Boston Summit two days ago between myself, Matthias
Clasen and David Zeuthen and we have agreed on the "way forward" for
dealing with all of the GVariant/DBus related issues in GLib that
involves the merging of the required patches to glib.  Hopefully this
happens in the coming weeks.

Thanks for the consideration


Cheers

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Vincent Untz]

Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :

> Hello
>
> dconf is a very conceptually simple key/value storage system with an
> implementation that makes it extremely efficient.  There have been 3
> tarball releases so far: 0.1, 0.1.1, 0.2.  More will be following in the
> coming weeks and months.
>
>
> I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop
> release set.

No.

Vincent (live from Boston, where Ryan is just on my left ;-))

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Ryan Lortie]

Hello

On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
> Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
> > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
> > desktop release set.
>
> No.

Pretty please?


Ryan (live from Boston, where Vincent is currently being pummelled with fists :))


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Sriram Ramkrishna-5]

You tell em, Vincent.  I've been wanting to tell him No for years now.

That said, Ryan, are you proposing this as a replacement for GConf?  That wasn't particularly clear in your initial mail.

sri

On Mon, Oct 12, 2009 at 8:30 AM, Vincent Untz <vuntz@...> wrote:

Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :

> Hello
>
> dconf is a very conceptually simple key/value storage system with an
> implementation that makes it extremely efficient.  There have been 3
> tarball releases so far: 0.1, 0.1.1, 0.2.  More will be following in the
> coming weeks and months.
>
>
> I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop
> release set.

No.

Vincent (live from Boston, where Ryan is just on my left ;-))

--
Les gens heureux ne sont pas pressés.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

--
-- Sriram Ramkrishna (sriram.ramkrishna_@@_@.gmail.com (remove _@@_)

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Diego Escalante Urrelo]

El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:

> Hello
>
> On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
> > Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
> > > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
> > > desktop release set.
> >
> > No.
>
> Pretty please?
>

No.

Diego (who is not even an r-t member but wanted to be part of the fun)

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Vincent Untz]

Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :

> El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
> > Hello
> >
> > On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
> > > Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
> > > > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
> > > > desktop release set.
> > >
> > > No.
> >
> > Pretty please?
> >
>
> No.
>
> Diego (who is not even an r-t member but wanted to be part of the fun)

Heh :-)

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.

Ryan, you might also want to detail out the benefits over gconf.

Also, devhelp has a branch for a port to dconf, iirc. So that might be
something that people might want to look at to get some idea of what
this involved.

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Javier Jardón]

2009/10/13 Vincent Untz <vuntz@...>:

>
> 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.
>
> Ryan, you might also want to detail out the benefits over gconf.
>
> Also, devhelp has a branch for a port to dconf, iirc. So that might be
> something that people might want to look at to get some idea of what
> this involved.

I've already created a page to track the progress and as a central
place to get info and examples about the migration to dconf/gsettings
[1]

So,  we can start the work if this is finally accepted ;)

Regards

[1] http://live.gnome.org/GnomeGoals/GSettingsMigration
--
Javier Jardón Cabezas
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Tue, 2009-10-13 at 13:12 +0200, Vincent Untz wrote:

> Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
> > El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
> > > Hello
> > >
> > > On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
> > > > Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
> > > > > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
> > > > > desktop release set.
> > > >
> > > > No.
> > >
> > > Pretty please?
> > >
> >
> > No.
> >
> > Diego (who is not even an r-t member but wanted to be part of the fun)
>
> Heh :-)
>
> 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.
>

I think it makes sense to do the migration for all the apps at once.
Also, the migration from gconf can be done directly from dconf, the
first time it starts, or even it could be clever enough to synchronize
changes from gconf every time it starts, to cover apps that migrate to
dconf later. That would remove the apps' responsibility to do the
migration, which would be a lot of code to have that in all
applications.

And yes, I support the move from gconf to dconf! :)

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Johannes Schmid-4]

Hi!

> 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.

I think the migration part is much more important to discuss than the
actual porting. And I don't think it would be a good idea to handle the
migration of keys inside applications because on the one hand they would
need to link against both gconf and GSettings and on the other hand this
will be a giant code duplication.

But in general I would really like to dconf for 3.0.

Regards,
Johannes


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Bastien Nocera]

On Tue, 2009-10-13 at 13:22 +0200, Javier Jardón wrote:

> 2009/10/13 Vincent Untz <vuntz@...>:
> >
> > 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.
> >
> > Ryan, you might also want to detail out the benefits over gconf.
> >
> > Also, devhelp has a branch for a port to dconf, iirc. So that might be
> > something that people might want to look at to get some idea of what
> > this involved.
>
> I've already created a page to track the progress and as a central
> place to get info and examples about the migration to dconf/gsettings
> [1]
>
> So,  we can start the work if this is finally accepted ;)

This is nice, but only one app has been ported. Could a few apps be
ported before people make a decision? Porting something like Evolution
would be a nice fire test for Dconf...

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Sandy Armstrong]

On Tue, Oct 13, 2009 at 7:34 AM, Rodrigo Moya <rodrigo@...> wrote:

> On Tue, 2009-10-13 at 13:12 +0200, Vincent Untz wrote:
>> Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
>> > El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
>> > > Hello
>> > >
>> > > On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
>> > > > Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
>> > > > > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
>> > > > > desktop release set.
>> > > >
>> > > > No.
>> > >
>> > > Pretty please?
>> > >
>> >
>> > No.
>> >
>> > Diego (who is not even an r-t member but wanted to be part of the fun)
>>
>> Heh :-)
>>
>> 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.
>>
> I think it makes sense to do the migration for all the apps at once.
> Also, the migration from gconf can be done directly from dconf, the
> first time it starts, or even it could be clever enough to synchronize
> changes from gconf every time it starts, to cover apps that migrate to
> dconf later. That would remove the apps' responsibility to do the
> migration, which would be a lot of code to have that in all
> applications.

I was thinking that too, given the time required for bindings to catch
up for Mono and Python apps, but doing a migration from gconf on each
login would cancel out one of the main benefits of dconf: improved
performance at login (if I understand the wiki correctly).

> And yes, I support the move from gconf to dconf! :)

Yeah, this is a good idea.

Sandy
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Cosimo Cecchi-2]

On Tue, 2009-10-13 at 12:41 +0100, Bastien Nocera wrote:

> This is nice, but only one app has been ported. Could a few apps be
> ported before people make a decision? Porting something like Evolution
> would be a nice fire test for Dconf...

I think having GSettings merged in GLib is the blocker here for starting
ports of application to the new infrastructure, as it happened with GIO.
So the question about whether we should migrate all at once or not (for
2.30) depends on how soon this will be available in released packages of
GLib.

Ciao,

Cosimo

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Tue, 2009-10-13 at 07:54 -0400, Sandy Armstrong wrote:

> On Tue, Oct 13, 2009 at 7:34 AM, Rodrigo Moya <rodrigo@...> wrote:
> > On Tue, 2009-10-13 at 13:12 +0200, Vincent Untz wrote:
> >> Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
> >> > El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
> >> > > Hello
> >> > >
> >> > > On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
> >> > > > Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
> >> > > > > I'd like to propose the inclusion of dconf for GNOME 2.30 in the
> >> > > > > desktop release set.
> >> > > >
> >> > > > No.
> >> > >
> >> > > Pretty please?
> >> > >
> >> >
> >> > No.
> >> >
> >> > Diego (who is not even an r-t member but wanted to be part of the fun)
> >>
> >> Heh :-)
> >>
> >> 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.
> >>
> > I think it makes sense to do the migration for all the apps at once.
> > Also, the migration from gconf can be done directly from dconf, the
> > first time it starts, or even it could be clever enough to synchronize
> > changes from gconf every time it starts, to cover apps that migrate to
> > dconf later. That would remove the apps' responsibility to do the
> > migration, which would be a lot of code to have that in all
> > applications.
>
> I was thinking that too, given the time required for bindings to catch
> up for Mono and Python apps, but doing a migration from gconf on each
> login would cancel out one of the main benefits of dconf: improved
> performance at login (if I understand the wiki correctly).
>

well, change "at login" with "at idle times", but I think it makes sense
to have dconf do the migration


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[michael meeks]

On Mon, 2009-10-12 at 11:27 -0400, Ryan Lortie wrote:
> dconf brings in no new external dependencies [except, see below about
> glib].  There is also a separate module, 'dconf-editor', however, that
> uses Vala.

        In terms of migration, is there any reason why we cannot re-implement
most of the gconf client library layered on top of dconf - with
presumably some automagic schema conversion in place of the
gconftool-2 --makefile-foo-install-baa ?

        If not, I would love to get fully up-to-speed on dconf by understanding
the differences that would make that a bad idea :-) [ presumably this is
an FAQ ]

        Otherwise, it sounds like a good idea to me; though - can you confirm
that the latest implementation does not scatter data we need to read on
login / app launch across tens of tiny files, and that the authoritative
data store is somewhat human readable ? :-)

        Thanks,

                Michael.

--
 michael.meeks@...  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Ghee Teo]

Vincent Untz wrote:

> Le mardi 13 octobre 2009, à 00:16 -0500, Diego Escalante Urrelo a écrit :
>  
>> El lun, 12-10-2009 a las 11:33 -0400, Ryan Lortie escribió:
>>    
>>> Hello
>>>
>>> On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote:
>>>      
>>>> Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit :
>>>>        
>>>>> I'd like to propose the inclusion of dconf for GNOME 2.30 in the
>>>>> desktop release set.
>>>>>          
>>>> No.
>>>>        
>>> Pretty please?
>>>
>>>      
>> No.
>>
>> Diego (who is not even an r-t member but wanted to be part of the fun)
>>    
>
> Heh :-)
>
> 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.
>  

Can the migration plan/tools also include migrating (even if it one off)
user's gconf values, since it is fairy common for users to move from
from version of GNOME to a newer one. The last thing we want to user
sees is that their previous settings are lost.

-Ghee

> Ryan, you might also want to detail out the benefits over gconf.
>
> Also, devhelp has a branch for a port to dconf, iirc. So that might be
> something that people might want to look at to get some idea of what
> this involved.
>
> Cheers,
>
> Vincent
>
>  

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Ryan Lortie]

On Tue, 2009-10-13 at 13:59 +0100, Michael Meeks wrote:
>       In terms of migration, is there any reason why we cannot re-implement
> most of the gconf client library layered on top of dconf - with
> presumably some automagic schema conversion in place of the
> gconftool-2 --makefile-foo-install-baa ?

There is a project to bridge dconf's backend to the libgconf API.  It
works for some *very* simple applications like gucharmap and the
calculator.  It was only made as a very simple proof of concept -- it
will need a lot of work before it has wide usability.  Help is massively
appreciated here.


>       Otherwise, it sounds like a good idea to me; though - can you confirm
> that the latest implementation does not scatter data we need to read on
> login / app launch across tens of tiny files, and that the authoritative
> data store is somewhat human readable ? :-)

"yes" and "yes" (but probably you meant "no").

Data is in a single file, and humans can read it with the right tools.
'cat' is not one of those tools. :)

Cheers


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Pierre Wieser-2]

Hi

Just my 10cents piece, as I'm afraid I'm not really involved
in the decision.

As a new maintainer - about six month on nautilus-actions -
I've already had to migrate from Gvfs to GIO, from libglade
to GtkBuilder, and, obviously, soon from GConf to dconf.

In GIO and in GtkBuilder, I had to suffer of regressions,
whether some api didn't exist in the new product (mostly
uri parsing in GIO), or bugs that were not fixed before the
migration decision (GtkBuilder: the id is no more unique
inside of a toplevel, not even fix today - see #579345).

I'm not able to estimate how much the new products are better
that the previous ones, but I, and I think other developpers
too, would greatly appreciate if new products had at least
same functionalities than the one they replace.

Really, guys, developpers need a minimum of stability to be
efficient.

I don't even talk of advanced users that we ask to directly
edit their GConf system because lot of applications have
preferences only editable through GConf editor.

All, we work to build a better free desktop.
But migrating three times in six months without any visible
gain is a pain.

Regards
Pierre

PS: and sorry for my bad english - I do my best efforts ;-)
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Stef Walter]

Ryan Lortie wrote:
> dconf is a very conceptually simple key/value storage system with an
> implementation that makes it extremely efficient.  There have been 3
> tarball releases so far: 0.1, 0.1.1, 0.2.  More will be following in the
> coming weeks and months.
>
>
> I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop
> release set.

Woot! Awesome.

I've been wanting to use dconf in gnome-keyring for a long time.

Starting up gconf at gnome-keyring-daemon startup (just to know which
components to run) has been questionable. Especially when gnome-keyring
is used in other desktop environments.

Cheers,

Stef
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Tue, 2009-10-13 at 17:18 +0200, Pierre Wieser wrote:

> Hi
>
> Just my 10cents piece, as I'm afraid I'm not really involved
> in the decision.
>
> As a new maintainer - about six month on nautilus-actions -
> I've already had to migrate from Gvfs to GIO, from libglade
> to GtkBuilder, and, obviously, soon from GConf to dconf.
>
> In GIO and in GtkBuilder, I had to suffer of regressions,
> whether some api didn't exist in the new product (mostly
> uri parsing in GIO), or bugs that were not fixed before the
> migration decision (GtkBuilder: the id is no more unique
> inside of a toplevel, not even fix today - see #579345).
>
> I'm not able to estimate how much the new products are better
> that the previous ones, but I, and I think other developpers
> too, would greatly appreciate if new products had at least
> same functionalities than the one they replace.
>
> Really, guys, developpers need a minimum of stability to be
> efficient.
>
> I don't even talk of advanced users that we ask to directly
> edit their GConf system because lot of applications have
> preferences only editable through GConf editor.
>
> All, we work to build a better free desktop.
> But migrating three times in six months without any visible
> gain is a pain.
>

you are right, but this is not usual, it is just that you joined GNOME
development in the middle of the GNOME 2.x to 3.x transition :) Once all
these libs are settled down, things should go back to normal

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Pierre Wieser-2]

> ----- "Rodrigo Moya" <rodrigo@...> wrote:
> > >
> > you are right, but this is not usual, it is just that you joined
> > GNOME development in the middle of the GNOME 2.x to 3.x
> > transition :) Once all these libs are settled down, things should
> > go back to normal
>
> Well, Rodrigo, "j'en accepte l'augure."
> (don't know the english equivalent - means I'm willing to believe
> that - whatever is said 'normal' in Gnome world ;-))
>
> Regards
> Pierre

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list