Re: GDBus/GVariant plans for next GLib release



On Wed, 2009-11-11 at 09:22 -0500, David Zeuthen wrote:
> 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.

Yes, although it also needs a way to list the names of the children of a
path for GDBusSubtreeEnumerateFunc.


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

I had various issues with the dbus-glib version of mainloop integration
that forced me to rewrite it. I'm trying hard to remember exactly all
the details but they escape my memory. I know one thing was the lack of
unintegration support, which is in this API, so thats nice. The other
thing was something about the memory management of the sources and the
main context causing a reference cycle or something like that, which
caused problems when i was using per-thread dbus connections for sync
calls... Damn that lousy wetware memory...



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