Hiding internal DBUS use inside a library
John (J5) Palmieri
johnp at redhat.com
Thu Aug 25 15:08:09 PDT 2005
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:
dbus_connection = dbus_bus_get (DBUS_BUS_SYSTEM, error);
if (dbus_error_is_set (error))
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>
More information about the dbus