Re: GLib plans for the next cycle

[Ryan Lortie <desrt desrt ca>]

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.

- Why is there EggDBusVariant instead of GVariant?  How will these map?
  See below.

- Do we want glib depending on libdbus?
  It is my understanding that the intention is that glib is at the
  bottom of the stack.  I felt like the reason that the GIO/gvfs split
  occured the way it did was in a large part because the gvfs client
  would not be able to use libdbus if it was in glib.

- What of the license issues?
  GLib is LGPL.  libdbus-1 is not.  The recent attempt to relicense
  libdbus-1 failed spectacularly due to copyright in a large chunk of it
  having been acquired by a bank (or something?) when CodeFactory AB
  folded.

- How does it fit with gobject-introspection?
  It seems like there could be a lot of advantage here in terms of
  easily exporting objects on the service side without need for large
  tables, if/elseif/elseif statements or code generation.

- Do we need code generation?
  Somewhat related to the last question, clearly: maybe we can avoid
  having generated code.  There is precedent for generated code in glib,
  certainly (enums, marshalers, etc.) but adding more is still a
  significant decision -- particularly when alternatives are available.
  This is a huge ideological debate, of course: I'm not going to suggest
  that this approach is wrong, but I guess my preference would lie on
  the other side, and it seems like this isn't something that has really
  been flamed on as much as maybe it should be.  Havoc tried to bring
  this topic up in another thread and as far as I can tell it didn't
  get a whole lot of play there.

> There is also some work by Ryan Lortie on a Glib-compatible Dbus api
> called gbus. It is lower-level than EggDbus, and might be suitable as a
> replacement for libdbus. While I have no clear idea yet how EggDbus and
> gbus will eventually relate, it is worth pointing out that EggDbus' use
> of libdbus is an implementation detail that is not exposed in the api,
> so it would be possible to replace it by something like gbus later on.

GBus is in a completely different problem space than EggDBus, so there's 
not much toe-stepping going on here.  I'm not certain GBus is stable 
enough that I'd feel comfortable encouraging its uptake during this 
cycle.  In the meantime, that means that we'd have to deal with the 
license and external dependency problems that come with using libdbus-1. 
 It also means that we might be in trouble later if we find out that 
the abstraction was a tiny bit leaky.

I do intend to propose GVariant for glib this cycle -- I'm going to be 
creating a branch of the newly-converted glib git repository and merging 
GVariant into it soon.  Assuming all goes well, EggDBus could be using 
it at this point.  This would make future transition to GBus extremely 
easy and would avoid converting between two different value types that 
do essentially the same thing.

Once we release EggDBus with one variant type or the other appearing on 
the public API, we're more or less stuck that way forever.


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

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


Cheers