GLib plans for the next cycle

[Matthias Clasen <matthias clasen gmail com>]

With 2.20 winding down, I think now would be a good time to talk about
what should happen in Glib 2.22.

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.

This would allow us to move forward with several things in GTK+ that
will work much better if they can use DBus:
- session support
- unique application support

A while ago David put forward his work on EggDbus and wrote a very
detailed mail [1] with arguments for why it would be very good to have
DBus support on the Glib level, why dbus-glib is not good enough, and
how his EggDbus bindings work. His approach seemed to be well-received,
and I'd like to propose that we take a serious look at integrating
EggDbus in GLib 2.22.

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.

Of course, assuming we can agree on that having DBus support inside Glib
is a good idea, there are still going to be some contentious questions.
Let me list some, with possible answers:

- Where do we put this ? Inside libgobject (since it is more or less
DBus bindings for GObject) or inside libgio (since it uses the GIO async
pattern and some utility classes from GIO) or separate ?

   My proposal: Add it as a separate library, next to (or actually on
top of) GObject and GIO. Maybe call it GBus.

- What do we do about the added 16bit integer types that are supported
by the DBus protocol, but don't have corresponding fundamental types in
GObject ? EggDbus currently has fundamental types for them.

   My proposal: Just add the fundamental types to GObject. It would be
odd to ship fundamental types spread over several libraries, and int16
is really not worth fighting against...

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

When I sat down with David and tried to figure out what the minimal
necessities actually are, we came up with the following:

GLib                                   GObject

g_ptr_array_ref/unref
g_ptr_array_set_data
g_ptr_array_set_element_free_func
                                       G_TYPE_PTR_ARRAY
                                       g_ptr_array_set/get_element_type

g_array_ref/unref
g_array_set_data
g_array_get_element_size
                                       G_TYPE_ARRAY
                                       g_array_set/get_element_type
                                       g_array_new_with_type

                                       g_hash_table_set/get_key_type
                                       g_hash_table_set/get_value_type
                                       g_hash_table_new_with_types


Comments ?

Matthias



[1] http://mail.gnome.org/archives/gtk-devel-list/2008-December/msg00059.html