Re: DBus GLib API

[Rob Taylor <rob taylor codethink co uk>]

Rob Taylor wrote:
> (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.

To be clear - the solution I'm suggesting is to have the API version in
the library name, like gtk+ or gstreamer. We could just as well go to
dbus-glib-1.1 or dbus-glib-2. Personally I rather like the way Gstreamer
does it: major.minor, with minor being odd signifying that its an
unstable API.

>> 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
> _______________________________________________
> dbus mailing list
> dbus lists freedesktop org
> http://lists.freedesktop.org/mailman/listinfo/dbus