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

[Havoc Pennington]

Hi,

Thiago Macieira wrote:
>> Contradicting my previous mail a bit, conceivably this allows some
>> simple plugins or libraries to avoid caring about the main loop, though
>> it would only work if the plugin never needed a main loop for any
>> _other_ dbus-unrelated reason.
> 
> I agree that would be nice to have.
> 
> I also think it's not a feasible idea. The plugin/library has to require 
> that from the application. Which in turn makes it impossible to use said 
> plugin/library from a bare-bones application. It would have to do the 
> dispatching itself or link to a binding. This changes the requirements 
> for the library/plugin itself (i.e., you can't add D-Bus as a new backend 
> in an existing library).

Not all libraries and plugins are "transparent" - some the app will be 
using consciously, and thus the lib or plugin can impose the requirement 
that a dispatcher is added - remember a dbus object system mapping, for 
example, is a special case of libraries/plugins in general, which would 
clearly require dispatch to be set up.

This is something I'm currently relying on in some code, using the 
dbus-glib dispatcher but not its object system mapping.

We could also do the threads_init trick, so a plugin could have "add 
dispatch if there isn't any". Though, I think potentially this isn't 
that big a deal, as apps in a stack like GNOME should reliably be 
setting up dispatch, at least once we sort out the position of dbus in 
the platform generally (per that other thread I started about GNOME)

> Besides, this is a contradiction with "the binding can take over the 
> shared connection and do whatever it pleases with it".

It's simply allowed to have a dispatcher that does not support 
alternative object system mappings.

This dispatcher could either 1) use the shared connections in such a way 
that they don't allow an alternative mapping to hook in or 2) use 
private connections, which means the shared connections are not dispatched.

Either way, the dispatcher does not support an alternative mapping, 
though in case 2) it does allow an alternative dispatcher, which would 
then enable alternative mappings.

I think it's just a dispatcher feature/design-question whether it 
supports alternative object system mappings or not.

Havoc