Re: using dbus in the platform

[Havoc Pennington <hp redhat com>]

Hi,

Alp Toker wrote:
> > 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.

Who is "we"? I certainly did not agree.

I define GTK as an application framework[1]; it should support what apps 
need to do. This means talking to the desktop, and dbus is how that is 
done on Linux (and unix in general, of course).

For GTK to do this it needs some dbus implementation.

Note the "dbus.h is not included in gtk.h" point I made. i.e. We are not 
talking about libdbus in the gtk API; we're talking about using it 
internally. In theory another dbus implementation could be swapped in 
sometime, though I don't think that is a worthwhile or near-term likely 
goal. In practice, we will probably want to swap something else in right 
away on Quartz and Windows ports.

[1] some may define GTK as a UI toolkit only, but in practice it has 
already gone far beyond that, and IMO it's right to do so because nice 
APIs really require a broader "application framework"

>   * .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.

It is not "dead weight," it's needed to provide functionality. gvfs 
already relies on it, which all gnome apps will already be using. KDE 
apps also already rely on it.

Some implementation is needed in the C stack; I don't see a new one 
that's close to ready (nor do I think a new C implementation makes sense 
for free desktop purposes[2], but that's another debate).

We aren't going to use the .NET, Python, or Ruby bindings in C libraries 
like GTK or gvfs, so they are irrelevant here.

[2] it might make sense for embedded or something, since libdbus is 
optimized for flexibility and security, at some cost in both size and speed

>   * 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.

That is one reason why libdbus is *designed* for language binding, and 
for sharing the DBusConnection object among object system mappings, and 
it is not encouraged to reimplement DBusConnection.

A basic assumption of the GTK+ and freedesktop.org "stack" to date is 
that shared code among languages / projects is written in C.

As I've said, I think it's a worthwhile tradeoff[3] in .NET or Java to 
reimplement, because there is value on those platforms to a 
zero-native-code solution. However, reimplementing DBusConnection in the 
languages that already heavily rely on native code (C, C++, Ruby, 
Python) is simply a bad idea[4], for the reason you give among others.

The shared code that leads to a single connection *must be* in C, 
because we need to use it in gvfs, GTK, and other elements of the C 
stack. This has been known for years, and that's why libdbus is designed 
the way it is.

[3] Even in the managed languages like .NET and Java, it's a tradeoff, 
though a worthwhile one. One price of avoiding native code is multiple 
bus connections - this could potentially be dynamically avoided at 
runtime, though, if libdbus is found to be present. Another major price 
is making it harder to add a new feature, such as a new auth mechanism, 
in a way that spans all apps / the whole desktop. This price is higher 
the more reimplementations we have.

[4] Let me qualify this, I think it could be interesting to have 
reimplementations in these languages for use in some contexts, but I 
think it would be better if the bindings dynamically decided to push 
messages into the shared DBusConnection when libdbus is available. We 
can optimize this as needed to avoid extra copies of the message, which 
has been discussed. But the point is for a typical Linux desktop it is 
optimal to have all the apps going through the DBusConnection in libdbus.

>  >  - 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).

There is no problem making libdbus portable. The unportable part is the 
stuff *on* the bus. i.e. if we have a "Screensaver" interface defined 
for the free desktops (GNOME, KDE) that is not going to be present on 
Windows unless someone goes to some effort, and it's unclear to me that 
writing a dbus service to talk to the Windows screensaver API makes more 
sense than just having GTK talk to the Windows screensaver API directly. 
(For example.)

> 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.

This isn't why Bonobo did not go in (to 2.0, it was 2.0-era).

(Well, Bonobo *did* go in, in the same not-in-the-API optional sense I'm 
proposing D-Bus, since it's used by the a11y stuff that generally gets 
loaded at runtime. But leave that aside for a moment.)

You're right there was a period of time where at least some people 
thought there should be a libgnomeui layer that was the app framework, 
while GTK was only the UI toolkit (i.e. only widgets). I don't think 
this is the theory or the practice today, though.

Aside from that debate, the major problem with Bonobo was in the 
specifics, not the idea of IPC. Example specifics were neglect of 
lifecycle issues; the famous "recursive main loop" bug; widget-embedding 
and app framework interfaces that didn't make sense with the GTK API; 
and being GNOME-specific instead of least-common-denominator.

Having IPC and IO (dbus and gvfs) below the app framework is the correct 
layering, because the app framework needs to use this stuff. The app 
framework does not necessarily need to expose this stuff in the API, 
though, especially when it needs to be (or should be) done differently 
per-platform.

Havoc