using dbus in the platform

[Havoc Pennington]

Hi,

Simon McVittie wrote:
> I'm not convinced Gtk+ is the place to be experimenting with D-Bus
> integration. Can't we do the experimentation in a libgdesktopbus or
> libgnomebus or something, with convenience API for single-instance,
> notifications, etc., that hides libdbus, and if it turns out that in fact
> everyone wants it, push it into Gtk+ later?

The purpose of this is not libdesktopbus or libgnomebus; it's to flesh 
out and complete the GTK+ application framework.  We want to design the 
platform with high-level API goals like "display help" or "manage the 
screensaver" or "set preferences" and we use an implementation detail 
like dbus as required.

The point about using dbus is that right now that is how we're 
implementing this stuff on Linux. Windows has its own way, and GTK 
should use that way on Windows, rather than dbus.

If you look at the example "GtkDesktop" code I posted during GNOME 
summit, there is no hard dbus dependency there (well, no soft one 
either, I didn't get to coding that bit); if someone came up with a 
better way to implement the functionality, libdbus could be dropped.

GTK does not need to export an IPC API; that remains a separate library. 
GTK does, however, need to *use* an IPC API, both directly and 
indirectly because GTK should use GSettings and gvfs (for example).

In other words, the problem to solve is an incomplete app framework, 
that leads to keeping large swaths of deprecated gunk via libgnome, and 
a variety of one-off libraries that should be in gtk. dbus is only a 
tool to solve this.

The app framework questions have already been pretty heavily prototyped 
- via libgnome, gnome-vfs, libgunique, and so forth. So what's needed at 
this point is to take those lessons and roll them into the platform in a 
coherent way.

If we continued to do another prototype, following on to the previous 
ones, I'm not sure what hypothesis the experiment would be testing. If 
there are concrete lessons we still think we need to learn, then that 
might be OK, but experimentation with no clear questions in mind won't 
move us forward.

Please, let's stop obsessing about essentially tiny corner-case details 
of the low-level dbus API and protocol parsing, all of which are fixable 
with simple patches, when we have much, much larger problems - such as 
1) no reasonable high-level IPC API for C whatsoever and 2) major gaps 
in the app framework such as no GSettings, no way to show help, no way 
to do single instance.
http://lists.freedesktop.org/archives/dbus/2007-August/008238.html

Havoc