"DBus Embedded" - a clean break

[Simon McVittie]

On Thu, 20 Jan 2011 at 06:56:28 -0500, Thiago Macieira wrote:
> So D-Bus being slow is not a surprise, it's a realisation that no one has 
> invested proper time in optimising it.

... or in keeping up with its bugs, for that matter. I have some time available
to work on it at the moment, and I've been trying to drain the queue of bugs
in Bugzilla and do some general swamp-draining.

Review of patches would be much appreciated (anything with the patch keyword
and assigned to me has patches that I consider to be good to go).

One performance-related thing that I'm working towards is trying out optional
Linux epoll support for 1.5, as a way to stop the main loop being O(n) in
number of active sockets. This requires considerable main-loop refactoring,
but I'm getting there...

> I know the current implementation is slow. We all know this. What irritates me 
> is that people jump to conclusions that "since it's slow today, it's 
> fundamentally flawed, cannot be fixed, we should just write a new thing". There 
> is no proof in that statement above. We don't know for sure. 

Yes, that. dbus-daemon isn't perfect, but it works, and if everyone moaning
about its performance spent an equivalent amount of time trying to improve its
performance, we might not even need to have this conversation :-)

Now, I'm not at all sure that libdbus is the right basis for client-side
bindings (I think ndesk-dbus, dbus-java and GDBus may have done the right
thing by being reimplementations rather than libdbus bindings), but that's for
API and licensing reasons, rather than some fundamental design flaw. Note that
all of those interoperate with the reference implementation's wire protocol,
so it's not an either/or, you can have any or all of them in your platform
(and you don't need a "flag day" sort of migration, which is basically not
going to happen for any realistic distribution).

Much of the strangeness in libdbus is because it's the backend for dbus-daemon:
for instance, unlike GLib, it (theoretically) copes with malloc returning
NULL, because you don't want your system or session bus to crash on OOM.
One possible future direction would be for independent client libraries (like
GDBus) to talk to a dbus-daemon that's still based on libdbus.

    Simon