Re: GDBus/GVariant plans for next GLib release

[Alexander Larsson <alexl redhat com>]

On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote:

>  http://cgit.freedesktop.org/~david/gdbus-standalone/

I just read through this for basic review, and I must say that I like
it. Very nice stuff. Some comments:

In nautilus I'd like to have an object path which is basically a pointer
to another object. Say I have these objects:

/nautilus/window/1/tabs/1/view
/nautilus/window/1/tabs/2/view

Then i want something like:

/nautilus/window/1/active_view

That always points to the view object in the active tab.

Now, i could constantly be re-creating this object all the time, but
thats not really very nice. What i instead want to do is basically
register a subtree at /nautilus/window/1/active_view which dynamically
looks up which tab is active and then re-routes to the right tab.

To implement this cleanly I would need to be able to lookup an object at
a given path (returning the ifaces, vtables and user data) and to
enumerate the children of a given path. All this would be in-client
registered objects/subtrees only, and is enough to implement
GDBusSubtreeVTable for the "pointer subtree".

I don't see any call to dbus_threads_init() or
dbus_threads_init_default(). Surely this should be done if gthread is
enabled. Ideally in g_thread_init_glib(), but thats a bit hard for
something in libgio...

I'd like it to be possible to specify a non-default main context when
creating a connection with g_dbus_connection_new() or
g_dbus_connection_bus_get_private().

g_dbus_connection_send_dbus_1_message_with_reply() has a race condition
if called on a thread other than the one dispatching the reply. The
pending call may be completed before dbus_pending_call_set_notify() is
reached. See _g_dbus_connection_call_async in gvfs/common/gdbusutils.c
for a possible workaround.

The way e.g. properties are implemented is very static. There is no way
to expose an object with a dynamic set of properties (apart from
removing and re-adding the object with new introspection data each time
dynamic properties/methods can't be implemented? (lazy, i.e. not remove
and re-add each time they change). I guess this is sort of weird wrt how
dbus usually works, but might be useful when exporting an object from a
more dynamic language like javascript or python.

Maybe we should not claim to implement org.freedesktop.DBus.Properties
if set/get_property are NULL?

I'm not sure if I missed it, because i didn't try it out, but how do
registered object with a a child that is specified by registering a
subtree get enumerated when introspecting the registered object?

The foo_bar_error_quark example in gdbuserror.c clearly should just call
a standard helper that does all this, just given the pointer to an array
of data.

org.gtk.GDBus.UnmappedGError.Quark0xHEXENCODED_QUARK_NAME_.Code_ERROR_CODE
Why use a hex encoding for the quark name? Most gerror quark names are
quite readable, and it would be nice to preserve this in the encoding
used.

There are no bindings for dbus_connection_flush, which might be nice to
e.g. ensure that the reply sent from a message handler is immediately
sent since we may block or whatnot later. Maybe we want this?

gdbusnameowning.c:request_name_cb() - Isn't it racy to not subscribe to
NameLost/NameAquired until we're processing the request name reply? 
We could have gotten a NameLost message inbetween the RequestName reply
gotten and request_name_cb being handled by the mainloop, as the
request_name_cb is called from another idle.

g_dbus_server_new() wants a way to specify the GMainContext to use.

gdbusprivate.c has a bunch of code with a copyright notice from dbus
that is AFL 2.1 or GPL2+. I.e. not LGPL. This seems like a problem for
glib integration.

Are you aware of:
#define	G_PARAM_STATIC_STRINGS (G_PARAM_STATIC_NAME |
G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB)
It saves some typing.