Re: GDBus/GVariant plans for next GLib release



On Tue, 2009-11-10 at 10:06 +0100, Alexander Larsson wrote:
> > 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.

Good point. Hmm, so given an object path you'd want a list of registered
objects, e.g. an array with

   - interface_name
   - introspection_data
   - vtable
   - user_data
   - registration id

This should allow you to implement GDBusSubtreeIntrospectFunc without
any problems.

> > 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 think so, yeah.

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

I see. It's returned by dbus_connection_list_registered(). There are
tests for this btw, see gdbus/tests/export.c and the subtree
at /foo/boss/executives.

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

Should be possible to add this too.

Thanks,
David




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