GNOME and dbus (was Re: C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?))

[Havoc Pennington]

Havoc Pennington wrote:
> 8)
> 
> As I also said in that GUADEC mail, for C apps, I think apps are 
> suffering most from lack of high-level API to do things like 
> introspection, single-instance, tracking bus names, and matching 
> signals, so we probably should think about that in addition to tweaking 
> libdbus to death and/or reimplementing parts of it...
> 

Incidentally, for C apps I think it's hard to overemphasize this point. 
There's quite a large problem with the overall GNOME desktop's use of dbus.

If I had more time to devote, I think I would in order:

  1) offer enough additional API so that all the apps currently using
     raw libdbus at least get introspection and signal matching and
     single instance and tracking who is using your service and so forth
     right

  2) figure out how to make GTK loosely (e.g. runtime-optional)
     depend on dbus, so stuff like libunique and libnotify can
     be placed in a sane location in the platform

  3) get the Windows port finished up (which may help with 2)...)

 From a GNOME standpoint, the first two would be *huge* and make a giant 
difference, allowing the entire platform to finally be sanely put 
together instead of jumping through 
this-can't-be-in-gtk-due-to-dependencies hoops. Also it would greatly 
cut down on the lines of dbus-related code in C apps and libraries.

Much less code and more coherent platform = more efficiency, less bugs 
and complexity.

Entirely wrapping libdbus in an object system mapping was probably the 
wrong place to start with GLib bindings; ultimately if apps have to 
unpack a DBusMessage it isn't a big deal, that isn't the "hard part" 
about IPC, and doesn't address the other purposes of dbus such as 
tracking the lifecycle of both one's own app and the apps you are 
talking to.

Havoc