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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list