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