Hiding internal DBUS use inside a library

[Lennart Poettering]

On Thu, 25.08.05 18:08, John (J5) Palmieri (johnp at redhat.com) wrote:

> > 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

Yes we have. And didn't consider it usable for our needs. Why?

First, we want to retain the freedom to drop the DBUS dependency
without changing the API or ABI. Therefore we cannot export any DBUS
specific types (like DBusConnection) to the user. The public API of
our library doesn't use a single DBus symbol or definition.

Second, because we want to retain maximum compatiblity with our second
library ("libavahi-core") which does in-process what our first library
("libavahi-client") does over DBUS talking to a system daemon. For
avahi-core we need some kind of event loop abstraction anyway, so we
want to use the exact abstracion layer in avahi-clien, too.

> I don't think it is irrational to expose that much DBus in a
> library.

Maybe. But it it doesn't fit our needs and the same is true in many
other cases. Think of any plugins-based system daemon that doesn't use
Glib. Such as Apache or whatever. If an Apache module wants to use
DBUS it has to integrate the DBusConnection with the way Apache does
event dispatching. Therefore it will set the timeout/watch functions
of the DBusConnection to some glue code. If now another apache module
wants to do something similar the connection recycling *WILL* break
it. Unless of course, both modules use exactly the same glue code
implementations AND they are loaded and initialized at the same time. 

> 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.

That's not the point. 

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/