Hiding internal DBUS use inside a library

[John (J5) Palmieri]

On Fri, 2005-08-26 at 18:17 +0800, Trent Lloyd wrote:
> 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.

So having two mainloops seems weird to me.  A mainloop should provide
integration so anything that would need a mainloop would just use the
controlling applications mainloop.

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

I threads why not just used blocking calls?  The main purpose of a
mainloop is to emulate threads where the complication of threads is not
needed.  I can see the need for a mainloop in threads for some small
number of cases.  So I'm not going to argue with you on the point.

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

Why not both?  dbus_bus_get_private should be the same as dbus_bus_get
where you send in a DBusBusType.  Internally it should use
dbus_get_system_bus_address() for system bus connections.  This should
also be changed in dbus_bus_get to use dbus_get_system_bus_address() and
wherever else it is hard coded.

> 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

Oh and on the core/client thing I was just going off what Lennart had
posted in a previous e-mail about keeping the libraries compatible.  

-- 
John (J5) Palmieri <johnp at redhat.com>