Re: impending gdbus merge

[David Zeuthen <zeuthen gmail com>]

Hey,

On Sat, May 8, 2010 at 9:37 PM, Shaun McCance <shaunm gnome org> wrote:
> Some initial thoughts, after partially porting Yelp:
>
> * I think it's odd that this reuses GIOErrorEnum. It uses
> values like G_IO_ERROR_CLOSED and G_IO_ERROR_EXISTS. The
> 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.

I'm not sure I like a separate enum and GDBusError is already reserved
for transcoding errors in the org.freedesktop.DBus.* error domain. We
could add extra error codes to GIOErrorEnum for something else than
e.g. G_IO_ERROR_EXISTS.... but I think it's generally correct to use
G_IO_ERROR_CLOSED and others.

> * 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.

I know and while it may technically be a bit imprecise but I like the
fact that it uses the word proxy since it's all about proxies. So in
this case trading a little precision for familiarity and fewer
characters is warranted. I think.

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

What Matthias said, I think. Also, I expect us to have code generators
(see my reply to Mikkel) at some point in the future.

> * 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.

Lots of people been asking for this and we already use the verb 'call'
in gdbus(1). So I've changed all the client-side stuff to use call()
instead of invoke_method(), see commit 869b4c6.

Handling server-side calls is still GDBusMethodInvocation which I
think is fine - it's not used quite as often and using call vs.
method_invocation helps people separate client vs server facilities.

> * 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.

First, there are examples of programs where there is work to do before
you own a bus name. May not be interesting examples but that's not
really the point. The main point is that mostly everything else in
this D-Bus API is asynchronous and part of providing an programming
framework is also trying to get people to write code in a certain
style. The whole "move functionality out of main() into callbacks" is
part of that.

(Btw, be careful writing your own g_bus_own_name() implementation.
There's a couple of gotchas here and there...)

> * 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.

We don't have code generators yet. We might get that. See my reply to Mikkel.

> * 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.

OTOH the examples are part of the build system so they never go stale
which is a good trade-off (plus people can easily copy-paste them). I
think Matthias are going to nuke the headers but that's only going to
cut a couple of lines.

> And for the curious, here's Yelp's GDbus port:
> http://git.gnome.org/browse/yelp/commit/?h=gdbus&id=b3f98f21da89ffefd51f19f02391a563d69e4172
>

Thanks for trying this out!

Cheers,
David