Re: corba -> dbus

David Vanderson wrote:
I have attached a rough patch as a start towards goal #1 on:


Please comment and let me know if I'm even going in the right direction.

It looks like good code. I think something to consider is the transition path. That is, here are some possibilities:

 1. create a new config library/daemon along the plans.html lines, and
    port apps to use it
    - would install in parallel with and replace current gconfd
    - would need to somehow use the existing settings though; maybe
      it would have a read-only backend that loaded the current
      gconf configuration files
    - most importantly would be a lot simpler than gconf is

 2. remove the corba dependency from current gconf, so apps don't
    have to link to orbit etc.
    - may not be possible; worth asking release team what they think
    - would primarily be an optimization
    - the dbus interface used would preserve a lot of the fugly
      from today's gconf, so probably shouldn't be the same as
      a nice clean org.freedesktop.Preferences interface we might
      use for #1

 3. other ideas here

afaik there isn't a lot of active maintenance of gconf, so you may find there isn't a lot of feedback on patches ;-) - I would suggest just plowing ahead (with a focus on running code), but trying to write things down and send out lots of info via planetgnome, desktop-devel-list, etc. A variety of Ultimate Config System architects will probably come out of the woodwork, I'd focus on ignoring them, writing working code, and keeping it simple (as in plans.html or improving on that as you see fit).

For the kind of simple I'm talking about, the plans.html page links to this old mail:

contrast that with the current gconf API...

I'm also poking around with a d-bus API to store prefs on Mugshot, right now that looks like (in outline):

 interface org.freedesktop.Preferences
   VARIANT GetPreference(STRING key, SIGNATURE expectedType) throws
     NotFound, WrongType
   void SetPreference(STRING key, VARIANT v)

this is obviously insufficient, e.g. listing child keys is needed, notification, etc. but I think the core dbus API would be something simple like this.

If anything on plans.html or doesn't make sense to you or you are wondering why I wrote it or what the thinking was, please ask... I may not remember, and/or the thinking may have been wrong, but it can't hurt to ask.

btw if you start more from scratch, a minor lesson of gconf is that the way it does the test suite is pretty sucky - if you look at the dbus source tree I was a lot happier with that. I think tests are pretty important for the config system since it stores so much user data and some parts of it are pretty tricky to get right.


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