[Fwd: Re: Re : gconf or not gconf]
charlie at openmoko.org
Tue Jun 10 11:18:47 CEST 2008
I forward this message from Ryan Lortie. Can someone add him into the
white list of the mailing list ?
-------- Forwarded Message --------
> From: Ryan Lortie <desrt at desrt.ca>
> To: Guillaume Chereau <charlie at openmoko.org>
> Subject: Re: Re : gconf or not gconf
> Date: Mon, 09 Jun 2008 11:51:19 -0400
> On Mon, 2008-06-09 at 14:21 +0800, Guillaume Chereau wrote:
> > Hello Ryan.
> > Mickey just forwarded me your email, that couldn't get to the openmoko
> > mailing list.
> > I am looking at the dconf project right now.
> > It may be what I am looking for, but I am still not sure. There are two
> > things that are preventing me from choosing it :
> > 1 - I can't make it work correctly. After installation, I try something
> > like :
> > dconf-set /test "int16 10"
> > And it does nothing. There are no error messages, and the return value
> > is 0, but nothing has been set. If I use debug mode, I get this
> > message :
> > stack-api-DEBUG: >> set (0x804b700, '/test', <int16 10>) =
> > DCONF_FAIL_COMMUNICATION
> dconf reads directly from the database for itself, but requires a server
> to handle writing. This was done because the read case is expected to
> be very much more common than writing (for example, booting into GNOME
> is 2000 reads and no writes). The dconf daemon is supposed to be
> dbus-activated on the first write. What you're seeing is very likely a
> failure for that to happen properly -- probably caused by dbus being
> unable to find the installed .service file (which happens if you install
> in another prefix). Try running the daemon manually.
Ah, hum... yes it seems I did something wrong on my machine by
installing different dbus version :-)
> You're looking at very much pre-release code.
> > I am not sure where the problem comes from. Can you help me with that ?
> > Do you have a mailing list where I could ask this kind of question ?
> This is a one-man project thus far. :)
> > 2 - I can't find the DBus API online. It is very important for me. In
> > fact to have this DBus API well documented is even more important than
> > having the implementation working.
> There is this:
> The strange calls you might be wondering about:
> Gettable queries if a key exists in the store. Settable queries if a
> key can be set (ie: it is not a read-only "mandatory" key).
OK, I like this ! The D Bus interface is simple.
> Notification is performed with a signal. The first argument is simply
> the path of the key that changed. Applications are able to register
> dbus watches for changes that interest them in such a way that the
> configuration daemon can come and go without losing track of the client
> requests. It works due to this patch (allowing fancy match rules):
> Transactions are not in the API yet, but they are planned. The change
> notification signal will be impacted.
> > About GSetting : I like the idea, but my interpretation of
> > freesmartphone is that we only define the DBus API. If there is a
> > library to ease the use of the DBus service, that is fine, but I don't
> > think it should be included into the standard. That is : all the
> > applications that use the DBus api will be "freesmartphone compliant",
> > regardless of the layers they want to put on top of it.
> dconf should appeal to you quite a lot, then. Even though the
> client-side library can access the database file directly for
> performance reasons, it is also completely capable of using the 'Get'
> method on the dbus service for the exact same results.
> If you could forward my message to the list, or fix the configuration,
> it would be appreciated :)
I can't do it by myself, I guess Mickey is the admin.
OK, I though a lot about what I should use for configuration management.
I have to say none of the available options (dcong, gconf, uniconf)
really please me.
Today I did a small python implementation of the kind of service I would
like (the main idea : the configuration server is "profile aware"). I
will send an other email to explain this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the smartphones-standards