David Vanderson wrote:
> I have attached a rough patch as a start towards goal #1 on:
>
> http://www.gnome.org/projects/gconf/plans.html
Yay!
> 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:
http://mail.gnome.org/archives/gconf-list/2003-May/msg00000.html
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
http://www.gnome.org/projects/gconf/plans-spec.html 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.
Havoc
_______________________________________________
gconf-list mailing list
gconf-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gconf-list
