Re: using dbus in the platform

["Brian J. Tarricone" <bjt23 cornell edu>]

{Whoops, re-send.  I brain-farted and addressed to the wrong mailing list!}

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