Re: GLib plans for the next cycle

[David Zeuthen <david fubar dk>]

On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
> Hi
> 
> Matthias Clasen wrote:
> > One thing that has been tossed around for a long time is that it would
> > be really good to have DBus support on the Glib level.
> 
> Agree strongly, but I'm not sure of the timing.  A couple of people have 
> raised a few questions with me recently (in light of the noise I've been 
> making about GVariant and GBus) about how this could be happening yet.
> 
> A few of the concerns that were raised:
> 
> - How will compatibility between EggDBus and GBus be?
>    I think this is not a very big concern, actually.  These two things
>    are currently aimed in very different directions.  GBus is very
>    low-level at the moment, mostly only implementing things that EggDBus
>    currently uses libdbus-1 to do.

Right, the point of the EggDBus effort is really just to provide a
reasonable object mapping for C programmers using GObject, e.g. the
focus is really the C object binding. Yes, this involves code generation
(and way too much code at the moment but that is fixable) since we care
about things like type safety and other crap.

Anyway, so Havoc made a good point that we should also making things
easy for non-C language bindings on top of GLib so he wrote a big
laundry list of things that I largely agree with (that won't affect the
C object binding that EggDBus gives you) and I'm planning to implement.

Presumably if EggDBus is using GBus instead of libdbus-1 this would have
to come from GBus ;-)

Some relevant threads

http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00121.html
http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00123.html
http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00026.html
http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00030.html

So, yeah, from a 50,000 feet perspective you are right that it's not
important for the EggDBus C object binding whether libdbus-1 or gbus or
whatever is used. The important point, however, is that the non C object
binding stuff is reasonably efficient so it's usable by non-C object
mappings without having to copy a lot of values around and allocate
memory to free it again nano-seconds later.

License issues aside, I'm not exactly sure why we'd want to avoid using
libdbus-1. My view has always been that application programmers should
not even have to know that libdbus exist because they should be using a
language specific object mapping that hides libdbus-1... using either
generated code or varargs-ish functions depending on your taste and the
size and complexity of the D-Bus service you are providing and/or using.

> > - What do we do about collections ? EggDbus adds typesafe GObject
> > wrappers around GHashTable and GArray. Other people have grandiose plans
> > to force java/.net style collection interfaces into GObject.
> > 
> >    My proposal: Dodge the issue by just adding the minimal necessities
> > to GObject: a type for GArray (GHashTable already has one), and an api
> > to associate element type information to arrays and hash tables.
> 
> I suspect that this will be insufficient.  In general, the GType system 
> isn't powerful enough to express DBus types properly.  This is what lead 
> to the creation of GVariant.
> 
> Even if we have support for querying the element type of an array, for 
> example, we can get into situations where we can still have type errors. 
>   Consider the case of an array of arrays of strings (which is a fairly 
> simple DBus type: "aas").
> 
> In this case, if you have a GArray, and query its type you will see the 
> answer is "G_TYPE_ARRAY".  This doesn't help you very much.  You have to 
> grab one of the inside arrays and query its type.  If the top array 
> happens to be the empty array then you're really in trouble because now 
> you have no way of determining the (complete) type of this empty array.

If you are not using a D-Bus variant this information is explicitly
available as part of the interface contract and it is also in the the
introspection data

http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo

as a D-Bus signature. 

For d-feet D-Bus debugging / introspection style apps you can also get a
EggDBusInterfaceInfo struct by introspecting objects at run-time (again
as a D-Bus signature) using egg_dbus_object_proxy_introspect(). If you
are using a D-Bus variant the signature is available on EggDBusVariant.

The point is that you can always get to the D-Bus signature and from
that you can infer the complete type.

So, you are right that the G type system _alone_ isn't powerful enough
if we do it this way. E.g. you will need to augment the type with the
D-Bus signature and then you have all the information you need. I'm not
sure that's a big deal.

(Note that in for most real-life apps this is not a big deal. People
normally code their applications against a known interface contract
(e.g. they know the D-Bus API at coding time) so they know exactly what
a value will contain.)

> It's also not reasonable to (dynamically?) create a new GType for the 
> exact type of every distinct DBus signature you encounter.

If we wanted this we could have something like this

 #define G_TYPE_PTR_ARRAY(element_type)
 #define G_PTR_ARRAY_GET_ELEMENT_TYPE(type)

to do this. Just like dbus-glib has done forever.

The set of distinct D-Bus signatures you encounter in a app where you
would need to do this (e.g. no need to do this for primitive types) is
most likely bounded to a couple of dozen types at the most (unless you
are some odd-ball corner case like a D-Bus version of gconf-editor) so I
don't think this is a big deal at all.

     David