Re: corba -> dbus

[Havoc Pennington <hp redhat com>]

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