Hiding internal DBUS use inside a library

[John (J5) Palmieri]

On Thu, 2005-08-25 at 22:52 +0200, Lennart Poettering wrote:
> On Thu, 25.08.05 16:02, Colin Walters (walters at verbum.org) wrote:
> 
> > > In short: a library that uses the current API function dbus_bus_get()
> > > is simply broken.
> > 
> > Not necessarily - if the library doesn't install its own handlers on the
> > connection, but e.g. instead just does dbus_connection_send and returns,
> > or does dbus_connection_send_with_reply_and_block.  The former
> > definitely works, the latter *should* work conceptually; whether it
> > currently does or not is another question :)
> 
> Hrm, more advanced libraries (like mine) will need stuff like signals
> and thus integration in to the main event loop, and if they want to
> hide the internal usage of DBUS they will abstract the main loop API,
> hence use dbus_connection_set_watch_functisions(). 
> 
> Just using dbus_connection_send_with_reply_and_block() ain't enough.

Have you looked at what other complex libraries like HAL does?  It
leaves it up to the programmer to integrate D-Bus with a mainloop and
uses a user supplied connection:

 DBusConnection *dbus_connection;

 dbus_connection = dbus_bus_get (DBUS_BUS_SYSTEM, error);

 if (dbus_error_is_set (error))
     return FALSE;

 dbus_connection_setup_with_g_main (dbus_connection, NULL);

 libhal_ctx_set_dbus_connection (ctx, dbus_connection);

I don't think it is irrational to expose that much DBus in a library.
Besides if an application is using DBus the programmer should know
because semantics change when you are dealing with client/server
functionality.  Hiding it does not give any advantages.
 
-- 
John (J5) Palmieri <johnp at redhat.com>