Re: GDBus/GVariant plans for next GLib release

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


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:


Then i want something like:


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

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

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:
It saves some typing.

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