using dbus in the platform

[Brian J. Tarricone]

Alp Toker wrote:
> 
> I think you might have joined this discussion from the wrong angle. 
> There is no real debate that using D-Bus makes sense for traditional 
> desktop environments. NDesk, another GTK+ desktop environment, 
> implements dozens of Freedestkop standards, including several fdo D-Bus 
> specs.

Ah ok, I see -- I think I'd picked up on that a bit, but I didn't 
realise that that was the central issue/argument at hand.

> The issue is that Havoc is proposing to use libdbus, his own D-Bus 
> implementation, directly in GTK+. This means that desktop environments 
> like NDesk which use their own D-Bus library will incur the overhead of 
> multiple connections and conceptual breakage of two D-Bus 
> implementations in one process.

I believe Havoc said that there's a potential solution to the problem of 
multiple connections.  Can this be done, or does that only work in the 
case where you have multiple connections open that all use the same 
low-level library?

The code size/data size overhead of having two implementations of the 
same thing in the same process is unfortunate, of course.

> The problem is not unique to NDesk. Some half a dozen GNOME applications 
> also use NDesk.DBus or dependent libraries. Dozens of third party 
> applications that are neither part of NDesk or GNOME also use 
> alternative D-Bus libraries and will be affected by any decision to use 
> libdbus in GTK+ proper.
> 
> There is no reason why the proposed libdbus-specific functionality can't 
> be provided by some "libdesktop" library to be used by GNOME, XFCE and 
> traditional desktops. This has the added benefit that such functionalty 
> can simply be avoided by, say, GTK+ applications running on DirectFB, on 
> deeply embedded custom OSs etc.

Well, I guess that depends on where you think the functionality that 
requires dbus (or whatever other IPC mechanism) belongs in the toolkit 
stack.  D-Bus is an implementation detail of that functionality.  The 
same functionality could be implemented using CORBA/orbit, a custom 
protocol on top of XShm, yet another custom protocol over a unix socket, 
etc.  What matters is the functionality: regardless of implementation, 
where does GtkUnique, GtkHelp, GtkUrl, etc. belong?  I'd be very 
skeptical of the suitability of an API designed based on its low-level 
implementation details, details which could change drastically at any 
point in the future.

So, where does it belong?  With the current trend/belief that gtk should 
contain higher-level app-building primitives, I'd say these 
dbus-requiring things belong in gtk, and not in a 'libgtkdesktop' or 
whatever.

As for multiple implementations, why can't gtk have a simple pluggable 
IPC module, sorta like the IM modules or GtkFileSystem?  I know, I know, 
it's one more layer of potentially-unneeded abstraction, one more API 
that needs to be carefully designed since it can't really be changed 
later, etc...  But it would make it possible for ndesk (for example) to 
provide its own IPC backend (a thin wrapper around the ndesk dbus 
library, in this case) and avoid using libdbus at all.

Or is there another way to solve this problem without creating Yet 
Another Platform Library[tm]?

	-brian