using dbus in the platform
alp at atoker.com
Mon Oct 8 22:39:18 PDT 2007
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
* .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
* 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.
More information about the dbus