Disabling new D-Bus protocol features by default
Lennart Poettering
mzqohf at 0pointer.de
Tue Nov 9 14:43:20 PST 2010
On Tue, 09.11.10 19:35, Thiago Macieira (thiago at kde.org) wrote:
> With that in mind, and considering there hadn't been any types added in 5
> years, plus the discussions on adding float being shot down, many applications
> and bindings could have made the assumption that they knew about all
> types.
Well, I think it can be expected from all software projects that they
might improve and be updated eventually. In fact, the "libdbus-1" file
name already includes a version number, making pretty clear that there
will be updates in the future. A developer who assumes that the software
and protocols he codes against are set in stone and will never ever be
updated or extended is just naive.
> And in D-Bus 1.2, they did. We pulled the rug from under these apps.
No, we just made a compatible addition, for the usually accepted
definition of "compatible".
Of course you can always argue that if the GLIB_MICRO_VERSION version
changes from 26 to 28 this should be considered API breakage because
everything that did "#if GLIB_MICRO_VERSION == 26" would suddenly
break. But saying that would be crazy, because this interface was
implicitly clear to be something that is updated eventually.
And the way we extended the protocols goes into great detail to make
sure not to enable fd passing if the feature isn't negotiated. Of course
it is not 100% compatible, because code that does dlsym(dbuslib,
"dbus_can_send_type") which previously returned NULL suddenly doesn't
anymore. But this kind of 100% compatbility is way over-the-top, and not
how we usually define compatibility.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the dbus
mailing list