Re: GLib plans for the next cycle


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

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


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