Re: using dbus in the platform

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]