Hiding internal DBUS use inside a library

[Lennart Poettering]

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.

> > 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() 
> 
> But you're going to have a serious problem anyways if you have two main
> loops in your application.  In what situation have you found this to be
> a problem?

While working on Avahi, a free mDNS/DNS-SD responder for Linux. The
public API of the avahi daemon is published via DBUS. We provide two
libraries: libavahi-core and libavahi-client. The fomer allows the user to
embedd an mDNS stack into his applications (mostly for printers,
routers and the like), the latter is an abstraction around our DBUS
API for normal desktop applications. The two APIs are mostly
identical, making it very easy to switch between them. (just a little
search and replace). libavahi-core doesn't have anything to do with
DBUS. libavahi-client is a DBUS wrapper. Both use the same main loop
abstraction. For libavahi-client we needed to write some glue code to
connect DBUS to our event loop abstraction layer.

I can think of many other situations where dbus connection recycling
becomes a problem:

consider gnome-vfs with a backend which makes use of DBUS (e.g. to
show a list of cameras or something it connects to
org.fd.MagicCameraManager or something) . Consumers of the gnome-vfs API
don't want to know about the internal DBUS usage of an auxiliary
backend. And they don't want that their own DBUS usage is broken by it.

> > or
> > dbus_connection_set_max_received_size() 
> 
> Yeah...somewhat problematic, although this is kind of a specialized
> function.  It probably isn't something any library should be
> invoking.

dbus_connection_set_timeout_functions() and
dbus_connection_set_watch_functions() are surely functions that
libraries which want to do some kind of event loop abstraction for
asynchronous signals want to use.

> > And when does this connection recycling ever become handy? 
> 
> I think one of the goals was to reduce the number of open file
> descriptors desktop applications have.

Yes, that's the idea of recycling. But most libraries can't make use
of it (as I tried to explain above) and the main program shouldn't
need more tha a single DBusConnection anyway.

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