Re: impending gdbus merge

On Thu, 2010-05-06 at 14:06 -0400, Matthias Clasen wrote:
> Hey,
> I thought I should let everybody know that we are getting very close
> to merging gdbus into GLib. David has created a gdbus-merge branch
> where we'll stage things before the final merge to master. So, if you
> haven't payed attention to gdbus yet, or haven't looked at it in a
> while, gdbus-merge is the branch to watch in the next few days.

Some initial thoughts, after partially porting Yelp:

* I think it's odd that this reuses GIOErrorEnum. It uses
documentation for these distinctly refers to files. Using
a separate enum would make it easier for programmers to
look at all the types of errors they might encounter when
using the GDBus* APIs.

* g_bus_watch_proxy is a bit of a misnomer. A proxy is a
local object that represents an object on the bus. You're
not watching a proxy. You're watching an object.

* Convenience APIs for invoking methods using varargs would
be nice, automatically handling the GVariant stuff. See for
example g_settings_set.

* I don't really see any reason to use g_bus_ as a prefix
instead of g_dbus_. I understand that those functions are
standalone, and not "methods". But I don't think it helps
readability any.

* How entrenched is the word "invoke" in DBus land? "call"
is much shorter. And when you're writing C, the difference
between g_dbus_method_invocation_return_error_literal and
g_dbus_method_call_return_error_literal is substantial.
Not a big deal. I just like my 80th column.

* I didn't end up using g_bus_own_name because I wanted
something synchronous. Tell me if I'm missing something
here, but synchronous name ownership seems like the common
way to do single-instance activation. Try to own a name.
If you can, register stuff. If you can't, call a method
on the remote object. You can't do anything anyway until
you either own the name or know you can't, so there's no
point doing it asynchronous.

* g_dbus_connection_register_object says vtable can be
NULL, but it's not clear to me how anything would work
if it is. I had to write a marshaler and pass it in with
vtable. I got this for free with dbus-glib. I might have
missed something.

* A general note about documentation: having examples for
everything is great, but the examples have too much stuff
in them. You should cut examples down to the bare minimum
necessary to illustrate a point.

And for the curious, here's Yelp's GDbus port:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]