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

[Thiago Macieira]

Havoc Pennington wrote:
>2)
>
>For example, in the Mugshot client app, we use a lame object system
>mapping I came up with ad hoc. However, we use the mainloop/dispatcher
>from dbus-glib, and we have libraries in the same process which I think
>use dbus-glib's object system mapping.
>
>As another example, you can use the glib mainloop/dispatcher with the
>Python object system mapping, for example in a PyGTK application. [1]
>
>The object system mapping just assumes "something will do
>read/write/dispatch" and that's all it has to know.

Agreed. Those two things are tightly integrated in QtDBus, which is why I 
can't easily provide dispatching for the shared connections without 
taking over them completely, as it stands now. With a little work, I 
could make it not take over, but it would still create a costly 
QDBusConnectionPrivate object.

>This dispatcher vs object system mapping distinction does not change
>your fundamental point, but it does mean the thing that has to be
>globally decided on a shared connection is smaller and less
> consequential.
>
>It sounds like this doesn't work in QtDBus since the Qt object system
>mapping assumes the Qt dispatcher is used, but AFAIK the GLib and Python
>bindings for example don't make assumptions about the dispatcher (other
>than "it exists")

It could be any dispatcher, with one requirement only: the message filter 
function must be called on a specific thread, the one in which the 
QDBusConnectionPrivate object was first created on.

If that requirement is met, I could use any dispatcher. The dispatcher I 
wrote makes certain of that (actually, because the Qt event loop does 
that).

>Anyway, to simplify slightly (since there are actually N shared
>connections[2]), the question here is whether the conceptual global
>variable:
>
>  DBusConnection *the_session_bus;
>
>is in libdbus or in dbus-glib and QtDBus.
>
>I would say that either way, conceptually this global variable "belongs"
>to the single dispatcher in use for the given app.
>
>There's some very small utility to reducing the code each dispatcher has
>to write slightly, by having libdbus deal with the global variable,
>thread locking it, and zero'ing it out on disconnect.

I can't argue with that.

>I think there's some utility to allowing say Python object system
>mapping and GObject object system mapping to share a single connection
>and single dispatcher.

That would make a lot of sense. To do that with QtDBus, you'd have to do 
like the Ruby bindings by Richard Dale: abstract QtDBus itself and create 
QObjects (including run-time manufactured meta objects, etc.) I plan to 
add some convenience functions for creating bindings on top of QtDBus.

>If they don't share that, I don't think it's a tragedy; an object system
>mapping that requires a specific dispatcher can use a private connection
>and the only harm is a bit more overhead.
>
>(Though I think people do underestimate how big DBusConnection is and
>the potential network overhead of creating one, esp. if we make TCP work
>well.)

-- 
  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/ac4f2dca/attachment.pgp