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

[Thiago Macieira]

Havoc Pennington wrote:
>3)
>
>The shared connections are intended to be "claimed" by some dispatcher.

That doesn't answer the question of what happens if they aren't claimed by 
anyone.

>So it is fair game, IMO, for QtDBus to entirely take over the shared
>connections and just say "if you want to be in-process with QtDBus you
>have to use the shared connections as we set them up."
>
>It sounds like a lib or plugin as I described in 1) above won't work
>anyway, but QtDBus can still own the shared connections if it likes.
>It would just be a policy of QtDBus that it forbids non-QtDBus usage of
>shared connections.

That's how it is now.

>That is effectively the policy anyway, since QtDBus is not dispatching
>the shared connections, a plugin or lib as described in 1) won't work
>anyhow. Given that this is already true in effect, there's no reason
>QtDBus can't just take over the shared connection. There may be no
>benefit to doing so, but there's also no reason not to.

I think there are reasons for not doing so: applications that use the 
shared D-Bus connection without verifying *which* dispatcher is doing the 
work.

Anyways, it boils down to: I don't want people to access my 
DBusConnection. The easiest way to do that is to not use the one that 
libdbus-1 may give to others.

>We could add some API to essentially "assert" that only one dispatcher
>claims the shared connections. That might serve some of the same
>preventing-weird-bugs purpose as deprecating shared connections.
>
>dbus_set_shared_connection_dispatcher(const char *name,
>                                       gboolean allow_other_dispatcher,
>                                       DBusConnectionSetupFunc func,
>                                       void *data);
>or something like that.
>
>If allow_other_dispatcher it means we don't care if someone else
>dispatches as long as they call our registered callbacks (so e.g. a
>plugin could set a dispatcher "just in case", like threads_init).
>
>However QtDBus would have to do allow_other_dispatcher = false which
>would mean we abort() if someone else had already taken over the shared
>connections.

In which case it would have to use the private connections all over again. 
I still don't see the point in moving to the shared connections.

>We could also have something like
>
>  const char* get_shared_connection_dispatcher()
>
>which would allow object system mappings to do an
>assert(I have the right dispatcher)

What if it doesn't have the right dispatcher? Should it abort the 
application?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070802/41fe9da7/attachment.pgp