DBus GLib API (was: gnome-keyring should use DBus for discovery)

[Rob Taylor <rob taylor codethink co uk>]

(Changing subject appropriately, should have done this earlier..)

Havoc Pennington wrote:
> 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.

Hmm, there's a *lot* of libraries using dbus-glib-1 right now (13 on
Ubuntu Edgy, according to apt-cache rdepends). The aim would be to allow
us to break ABI at will without disturbing these current users. I guess
the right thing is to go to dbus-glib-2.

> 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.

The thing we want to do here is provide a way for users to attach
introspection information to their GObjects/GInterfaces, providing
GTypes for method parameters. That way a user can chose which GType the
dbus message is demarshaled into. I'd also like to provide some useful
helper macros for  making GTypes for plain structs.

> 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.

This is fixed in 0.73.

> 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.

I fully agree, hence why I want to basically freeze API on dbus-glib-1,
to provide us with some freedom for a more useful design.

Thanks,
Rob Taylor