(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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
