DBusConnection -> DBusGConnection woes

[Robert McQueen]

Havoc Pennington wrote:
> Ross Burton wrote:
>> Is there a sane way to handle this?  There is
>> dbus_g_connection_get_connection()() but no way of going the other way.
>>
> 
> I think no; the ultimate goal was to have dbus-glib bindings for the
> DBusServer stuff iirc, but that has never been done.

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.

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. If dbus-glib obtained private
connections in order to guarantee that the encapsulation was complete,
the effort could possibly be justified, but at the moment we just seem
to be forcing ourselves to encapsulate things with little tangible benefit.

I'd suggest we just turn DBusGConnection into a typedef for
DBusConnection, and make any mapping macros/functions into no-ops. If
this seems too radical, 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.

> Havoc

Regards,
Rob