Hiding internal DBUS use inside a library

[Havoc Pennington]

On Tue, 2005-08-23 at 21:48 +0200, Lennart Poettering wrote:
> 
> Honestly I think that the whole connection recycling thing is a really
> bad idea. The fact that one part of a process might call functions
> like dbus_connection_set_timeout_functions() or
> dbus_connection_set_max_received_size() on a DBusConnection and
> overwrite values other parts already set earlier without even knowing about it
> is a royal error source. 

It's possible we should move the connection sharing up into the
bindings.

With GNOME apps, set_timeout_functions() will always be called by the
GLib main loop stuff, and set_max_received_size() would never be called
(it's a specialized function used only by the message bus).

> And when does this connection recycling ever become handy? What is the
> gain of the added complexity? Either a connection is created by a
> library, in which case recycling is a bad idea due to the reasons
> described above. Or it is created by the main program, in which case
> one can asssume that the programmer knows what to do and shares
> the DBusConnection on his own behalf if he wants to.

The point is to share the connection among code modules. i.e. inside
GNOME, all GNOME libraries and portions of a GNOME app can use the same
connection because it's assumed/defined that DBusConnection is used with
the GLib main loop.

We do the same thing with the X display connection maintained by GTK.
(And KDE does the same with the one for Qt.)

If you don't share the connection you'd have 20 open connections per app
or more quite easily, which is noticeable overhead.

> Did I miss something? Is there already a way to deal with this cleanly?

There is a way to do it with today's libdbus, because nothing about
dbus_bus_get() is magic. You can just call
dbus_connection_open_private() then dbus_bus_register(); the rest of the
code in dbus_bus_get() is just maintaining the shared connection global
variable.

Havoc