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

[Havoc Pennington]

Thiago Macieira wrote:
> Havoc Pennington wrote:
>> 6)
>>
>> The reason to deprecate as you say is "to avoid silly errors of
>> applications using the connections shared by libdbus-1"
>>
>> Do we really have a problem here in practice, though? I would expect
>> that if someone did this their lib or plugin or whatever would just not
>> work and they'd notice pretty quick.
>>
>> If this is biting people I'd like to address it somehow.
> 
> And why allow the problem to exist in the first place?
> 
> By using a private connection in the first place, the problem can't exist.
> 

The reason is that the shared connection is in fact shareable now, at 
least sometimes or potentially. I have a reasonable expectation of at 
least two or three object mappings in some apps (GObject, Python, simple 
hand-rolled / direct libdbus usage).

An extra connection means:
  - developer-visible: in a dbus browser app, you'd see
    each extra connection as a separate app, rather than having
    the entire app in one listing
  - developer-visible: you can't do things like add a filter
    callback to get debug spew on all dbus traffic going in
    and out of your app
  - two more DBusConnection objects (which are large), one in the
    app and one in the daemon X N apps
  - two more sockets X N apps
  - at startup, several more blocking round trips to set up
    the connections and authenticate, which is noticeable
    over TCP at least X N apps

In the QtDBus/KDE case the expectation is that the shared connection is 
simply never created so it's a non-issue, but in a case like some 
GObject mapping, some Python mapping, and some direct libdbus usage in 
GNOME, we would expect all three to be created.

It's not like this inefficiency is the end of the world, but it's (I 
believe, in the GNOME case) not necessary.

Havoc