Re: GDBus/GVariant plans for next GLib release

[Alexander Larsson <alexl redhat com>]

On Mon, 2009-11-09 at 08:52 -0500, David Zeuthen wrote:
> Hey Alex,
> 
> On Fri, 2009-11-06 at 21:05 +0100, Alexander Larsson wrote:
> > 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:
> 
> Thanks for reading through it!
> 
> > 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".
> 
> Yeah, I guess that's a reasonable thing to add. How about?
> 
>  gboolean
>  g_dbus_connection_lookup_object (GDBusConnection *connection,
>                         const gchar           *object_path,
>                         const gchar           *interface_name,
>                         GDBusInterfaceInfo   **out_introspection_data,
>                         GDBusInterfaceVTable **out_vtable,
>                         gpointer              *out_user_data,
>                         guint                 *out_id);
> 
>  gboolean
>  g_dbus_connection_lookup_subtree (GDBusConnection *connection,
>                         const gchar           *object_path,
>                         GDBusInterfaceVTable **out_vtable,
>                         GDBusSubtreeFlags     *out_flags,
>                         gpointer              *out_user_data,
>                         guint                 *out_id);

This is not enough to implement GDBusSubtreeIntrospectFunc. I.E. I can't
get the list of interfaces supported at a specific object path.

> > 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().
> 
> Hmm, yeah, I was thinking about that. It's for specifying the mainloop
> for processing D-Bus messages, right?

Yeah.

> I was actually thinking that it might be nicer to always have a
> dedicated thread for handling D-Bus messages. This would be shared by
> all connections and it would just pop messages to the mainloops for
> method invocations and signals.
> 
> This is feasible even if g_thread_init() has not be called, we'd just
> use libpthread directly (which libdbus-1 pulls in already).

Would it be possible to lazily postpone this until e.g. g_threads_init()
was called, or when another thread uses dbus? It seems a bit of overhead
to add a new thread to every simple single-threaded gtk+ process on the
planet.

> > 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?
> 
> I'm not sure I understand this question - can you clarify?

In the implementation of enumerate for a path, say /foo/bar, where you
have registered a subtree at /foo/bar/gazonk, how does the
implementation of enumeration of /foo/bar detect that there is a child
called "gazonk" that should be mentioned in the introspect 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.
> 
> Yeah, we can choose another encoding that hex. The problem is that D-Bus
> is very strict about what characters it accepts for names - in
> particular, '-' is not accepted. So we'd need some kind of way to escape
> things. That's doable though.

Well, you could hex-escape anything not allowed by d-bus.
You can see what i did in gvfs at
gvfs/common/gdbusutil.c:_dbus_message_new_from_gerror().

> > 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.
> 
> Maybe we can use the code from GVfs for this?

Thats got the main loop integration, which i've written from scratch.
However there is no server support.

> 
> Btw, what do you think about
> 
> http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html
> 
> I was going to do this as well.

Looks good to me.