DBusConnection -> DBusGConnection woes

[Havoc Pennington]

Hi,

Robert McQueen wrote:
> I've been thinking about this and I've basically decided this is a bit
> of a pointless encapsulation. It seems to be motivated by the idea that
> either you're using the raw libdbus connection, or you're using a glib
> encapsulated connection. Unfortunately, this isn't a very sound
> encapsulation because in reality there are no guarantees that a given
> connection is being dispatched by glib, because the user can always
> obtain the real libdbus connection by using the above function (which
> I'm surprised to see exists), or talking directly to libdbus to obtain
> the same shared connection and then insert filters or replace the
> watch/timeout functions and break the glib bindings anyway.

For a given app it has to be defined which main loop is going to be 
attached to the shared dbus connections and how dispatch will work. All 
libraries the app is using have to be either configurable on this point, 
or in agreement with the app.

The assumption is that for a given app it will be using a "stack" of 
libs, such as the GLib stack or Qt stack, so there will in fact be this 
agreement.

There are supposed to be three separately-includable headers:
  - plain libdbus (like Xlib)
  - GLib bindings (like gdk/gdk.h)
  - GLib-bindings-to-libdbus-mapping (like gdk/gdkx.h)

The reasons for the no-raw-libdbus header include:
  - makes it simple to avoid breaking encapsulation; you know which API
    to consider using
  - reduces the amount of stuff #included, which speeds up compilation
  - simplifies the API - much of libdbus complexity is just to support
    the bindings, the application-interesting API is much smaller than
    dbus.h

As with GDK, if you start using the "raw" mode (like gdkx.h) things get 
a little fragile and you have to know a bit about GDK internals to keep 
from messing up GDK. Similarly, if you want to confuse the GLib bindings 
you certainly can. But don't.

> There are howeber totally legitimate cases that Ross has found (being a
> DBusServer for connections you wish to export GObjects on) that we are
> failing to serve at the moment.

I don't think it should be complex to encapsulate this, though.

 > at the very least it would be good to make a
> variant of setup_connection_with_g_main which returned you the
> DBusGConnection, which would at least weakly guarantee that a
> DBusGConnection was being dispatched via the glib mainloop.

I would say this is already guaranteed, except in the "people can do 
arbitrarily crazy things" sense. But, don't do that then.

Havoc