Hi, Brian J. Tarricone wrote:
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.
I think what you want to be pluggable is the backend for say "show an URL". To show an URL, GTK could use dbus, or could call a Windows API, or whatever.
The idea here is not to have an "official GTK IPC system" - it's to have GTK use platform APIs, which may happen to use an IPC system. For example, the graphics APIs on "normal" Linux (not embedded) generally use the X11 protocol, so to do graphics on that platform, GTK uses the X11 protocol. On other platforms, it doesn't. dbus is pretty much exactly analogous.
To simplify all the platform special-casing, we do have freedesktop.org and try to keep some of the open source desktop platforms such as GNOME, KDE, XFCE in sync, which means less work for GTK+. D-Bus is certainly intended to be part of this shared stuff, at least for somem subset of open source platforms.
To the extent there are other open source platforms that don't fit in to some of the existing specs, such as Hildon or NDesk, GTK+ will have to special-case them when they are different, just as it has to special case GNOME vs. Windows vs. Mac vs. DirectFB.
Havoc