Re: using dbus in the platform
- From: Alp Toker <alp atoker com>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-devel-list gnome org, dbus lists freedesktop org
- Subject: Re: using dbus in the platform
- Date: Tue, 16 Oct 2007 19:00:15 +0100
Havoc Pennington wrote:
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.
The ideas being thrown about involved pre-loading a module that would
provide IPC functionality, rather than a hard-coded dependency on D-Bus.
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"
I appreciate that you didn't propose exposing libdbus directly in the
API. The problems I've described exist even if D-Bus is to be used
behind the scenes by GTK+. They are not hypothetical, but real problems
that will appear if ever GTK+ starts to open D-Bus connections.
* .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.
The functionality is welcome, but it should be provided in a separate
library, just like gvfs.
Is there any technical reason why it needs to be included in GTK+? Does
it make use of GTK+ internals? I suspect not.
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.
Nobody suggested this. This is a straw man argument.
[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.
libdbus was not well-suited to language binding when I reviewed its
documentation. It lacked necessary entry points for
marshalling/demarshalling data, ABORTed under recoverable error
conditions and permitted, even encouraged consumers to disconnect shared
connections.
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.
If "DBusConnection" is so easily shared, why are various language
bindings today opening private, unshared connections to the bus? It is
evident that reality has not matched expectations here.
In my experience with libdbus, I've found that it sets low standards for
interoperability and fails to achieve them.
Given these realities, I cannot see how libdbus in its current state
could be an appropriate dependency for GTK+.
> - 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.
Leaving D-Bus use out of GTK+ will provide everyone with more choice and
modularity -- the features you have in mind belong elsewhere in the
platform. Developing them outside of GTK+ will let you prototype, test
and deploy your own code faster whilst leaving others free to experiment
with different approaches.
Keep in mind that not everyone uses GTK+ in the same way that we do in
GNOME.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]