Hiding internal DBUS use inside a library

[Trent Lloyd]

On Thu, Aug 25, 2005 at 06:08:09PM -0400, John (J5) Palmieri wrote:
> 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);

Also consider situations where the applications doesn't know about the
'other' dbusconnection.

For example a shared library makes use of avahi, and the application
makes use of avahi, or two entirely separate parts, 1 is using dbus and
1 is using avahi, or even two entirely separate parts of the code making
use of avahi with two separate main loop adapters.

Additionally, I see this being a problem in threads, although I'm not
sure how much D-BUS does to avoid that, it may well work (although, if
it does I have no idea hwo it handles executing handlers in the otehr
thread, or perhaps thats simply not supported, but it should be), also
consider different event loops in two threads, this might not happen
in glib but glib isn't the whole world. :)

Any which way you look at it, these use cases should not in broken.

In particular, the problem we had was that the system bus address is not
exported in any way, and the claims in dbus-bus.c that its 'hard
coded' are not in fact as hard coded as you'd like it to be, because its
defined on $localstatedir.  (I suspect that comment is out of date)

I will write a patch and submit it to the bug walters pointed
out -- but what would you prefer
 a) dbus_bus_get_private()
 or b) dbus_get_system_bus_address() (This, vs a defintiion, so it can
 check the env too or whatever other behavior decides to be supported
 in future)

Personally, I'm fond of the former but I think the latter should also
exist.

(Oh, when I wrote the patch to use dbus_connection_open_private, I did
make it respect $DBUS_SYSTEM_BUS_ADDRESS if set, which seemed to be in
line with what libdbus would do, but thats pretty much never set)

Trent

> 
> 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>
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus

-- 
Trent Lloyd <lathiat at bur.st>
Bur.st Networking Inc.