Re: using dbus in the platform

[Alp Toker <alp atoker com>]

Havoc Pennington wrote:
> I want to propose moving forward on this front. Here is a strawman approach.
>
> 1) Create a GLib main loop integration library, separate from
> dbus-glib (dbus-glib should now depend on this main loop integration
> library). Note the distinction between a "framework integration" of
> libdbus, and an "object system mapping." The idea here is punt on
> object system mapping for now (let it keep evolving), but have a small
> framework integration lib. Concretely, this is
> dbus_connection_setup_with_g_main() and not a lot else.

This makes sense since GLib main loop integration is a vastly simpler 
problem to solve than GObject mapping, and there are many use cases that 
require only the former.

> 2) GTK+ has a dependency on dbus, on X11 only, for "desktop
> integration" features to work. (See list of examples above.) By
> "dependency" I mean specifically:
>  - dbus.h is not included in gtk.h
>  - gtk or gdk contains interfaces such as settings, notifications,
> single instance, launch help viewer; on X11, these are implemented
> using libdbus (suggest a cut-and-paste of hippo-dbus-helper.[hc] or
> equivalent is used internal to gtk)

I believe that we've already discussed this possibility and duly 
dismissed it as unworkable. To depend on libdbus in GTK+ is a clear 
layering violation.

 * .NET, Java, Ruby (and soon Python) applications each make use of 
their own D-Bus implementations. There has even been talk of a new C 
implementation. There is little sense in imposing the dead weight of 
libdbus on GTK+ applications using these platforms.

 * Moreover, multiple implementations of the D-Bus client in one 
process will lead to multiple connections to each of the system and 
session bus daemons.

 * This leads to wasted resources, with memory use and wakeups 
potentially doubled.

 * Confusion and a ruined conceptual model as individual processes are 
allocated multiple unique names.

>  - on Windows and OS X, these interfaces are implemented in some
> native way (though it could make sense to rely on a dbus port in some
> cases, I don't know)

 * The lack of portability you mention is an artificial limitation (or 
perhaps one imposed by libdbus). We have had people happily using 
Freedesktop notifications in GTK+ applications on Win32 for some time, 
and to go X11-only would be a step backwards. I believe the new Python 
D-Bus implementation is also very portable.

> 3) Apps that want to use dbus for custom IPC would choose an object
> system mapping (such as dbus-glib) and use it, or just use libdbus
> directly, but gtk would not be involved - for now no object system
> mapping is blessed

Modularity is one thing we've been getting right all these years. The 
functionality that you've discussed is definitely welcome as an optional 
part of the platform, but is not appropriate for integration with the UI 
toolkit, any more than, say, Bonobo would have been suitable for GTK+ 1.2.