David Vanderson wrote: > My current plan is roughly: > > 0. periodically send questions and updates to gconf-list > 1. get gconf to go over dbus > 2. simplify gconf implementation > 3. make a new plan > > Do you see any problem with this plan?
The issue is whether you can get benefit from it, that is, if you add dbus to the current codebase but can't get rid of corba (due to ABI issues for example) then you haven't really accomplished all that much. There may be some gain from it, like getting rid of the lockfile. But you don't need to use dbus for most of the ipc for that, you could use dbus only to use a bus name for lifecycle tracking but not to replace the corba stuff. I don't think the dbus work to support current dbus API will be the same as that to support a simplified API, fwiw, since the current dbus API's complexity is also found in the current protocol and data model. On the other hand, perhaps it makes sense to have a new daemon eventually that is dbus-only, and have libgconf able to talk to that new daemon over a compatibility protocol that supports the old gconf type of operations. It's probably a good starting point to mess with the current code some and try to get a feel for it, but you may find you need to toss a lot of the resulting code once you understand things more fully. > Is gconf-list the right place > for this stuff? Certainly, though posting an update to a broader audience such as desktop-devel-list might be good from time to time also. You probably want to get a bit further along first. > For instance, switching from corba to the per-session dbus would make > gconf a per-session program. How should that work when a person logs in > twice? It's already per-machine (it puts the lockfile in /tmp by default now iirc, though for a while it put it in the homedir by default). The semantics are that whichever gconfd writes to the xml files last will win. Which is also how most non-gconf apps work if you run two copies. It's not perfect but it works fine in practice as long as you write the files atomically to avoid corruption. Havoc _______________________________________________ gconf-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gconf-list
