[patch] remove DBusGPendingCall
Havoc Pennington
hp at redhat.com
Tue Jul 5 22:37:26 PDT 2005
On Tue, 2005-07-05 at 13:37 -0400, Colin Walters wrote:
> As discussed before, the DBusGPendingCall object's lifecycle is really
> tied to that of the proxy, so this patch removes it entirely from the
> API. Now the begin_call API looks like:
>
> guint dbus_g_proxy_begin_call (DBusGProxy *proxy,
> const char *method,
> DBusGProxyCallNotify notify,
> gpointer data,
> GDestroyNotify destroy,
> GType first_arg_type,
> ...);
>
I was with you until I noticed the guint return value, which to me means
the change really is:
- have the proxy own the only refcount on the pending call (aka call
id) rather than requiring the caller to own one, so no intermediate
variable is required - the good part
- use a guint instead of a typed pointer - I'm not sure about this one
or am I missing something as usual?
> When I was looking over the GNOME Service Manager, I noticed Ray had
> written a function very similar to this, which encourages me that this
> is the right idea. I think it is a nicer API, and more GLib-like.
My basic take on guint IDs in GLib is that they are crackrock - more
recent APIs support this view with e.g. GSource* replacing the old ID
API.
guints have at least three downsides:
- lack of typesafety
- inefficiency due to the hash table vs.
just pointer deref
- weird GLib-specific oddity
> Some other changes in this patch:
>
> o Updated all callers of begin_call (most of these were actually changed
> to just invoke dbus_g_proxy_call, since all they did was pair
> begin_call and end_call)
> o Now the proxy manager has its own special proxy for the bus, in order
> to reduce redundant code
This reminded me that the glib bindings are supposed to work in direct
app-to-app mode (no bus daemon) in theory, and I have no idea if they do
in practice.
> o Disabled async client side wrappers for now, sorry Ross! Will fix
> once this patch goes in.
> o Used GType qdata to map object info instead of global hash
>
Havoc
More information about the dbus
mailing list