Re: gnome-keyring should use DBus for discovery

Parallel install will be of limited value most likely if any *libraries* in the typical GNOME/GTK stack use dbus-glib, because you'll probably still use some of the same symbol names. That is, as soon as a lib in the stack uses a dbus-glib ABI, that ABI is locked in.

You might address this by strongly discouraging such a dependency in several places online and in the docs, or something, if changing ABI looks necessary.

I haven't been keeping up with dbus-glib in detail but two major changes I can think of might be 1) support for not writing an xml file by hand (presumably doesn't break abi) and 2) having introspect support in libgobject itself, thus deprecating the equivalent in dbus-glib.

Some of the data type bindings seem a tad inefficient and/or inconvenient (GHashTable of GValue type of stuff) but I'm not sure there's a lot to be done about that in C.

Another largish fix I noticed - I think dbus-glib still subscribes to *all* NameOwnerChanged, which is a little brutal for overall system performance (any name owner change wakes up all apps), I don't know if fixing this would break ABI but it'd be nice to fix.

In general usage of dbus-glib seems to be a little more widespread than the API maturity might warrant, but I guess I have conservative tendencies in this area.


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