Re: corba -> dbus
- From: Havoc Pennington <hp redhat com>
- To: David Vanderson <david vanderson gmail com>
- Cc: gconf-list gnome org
- Subject: Re: corba -> dbus
- Date: Fri, 23 Feb 2007 15:14:13 -0500
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
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]