Colin Walters ran the session with a short introduction to what GOI is. He said that GObject was ripe for doing this to: the type system already had a lot of what was needed to reach the goal of making it a lot easier to script our C libraries. A few things were needed to get there, though, mostly annotations.

Colin demonstrated how to annotate your C libraries to make them accessible from GOI. This annotation data contains simple declarations of what, for example, containers are being passed around by your pointers and whether you, the consumer, need to unref. it when done. (Take ownership.)

When running the annotation parser, an XML file is written to a .gir; the gir is then compiled to a .typelib which is an efficient binary format containing the same information. These are the two parts work together to make a language binding work without any additional work on the part of the language binding.

GJS is already ready. PyBank is the GOI-based Python binding. It's fairly complete at this point—some call conventions had to be worked out for compatibility. Colin is of the opinion that the legacy bindings shouldn't be replaced: where the work was done by hand, it should stay. New bindings should use PyBank and PyBank was developed in a way that makes sure that calls compatibility is preserved between the old and new bindings.

There was a question about using GOI to make bindings to objects creating in another language: Gtk# objects, for example. Colin said this is really, really hard. There's the issue of two GC engines per process and memory management issues that seem unsolvable in a sane way.

Shaun asked about rebasing gtkdoc on top of GOI to better extract the metadata from these annotations. Colin is looking forward to this but some work remains to get to that point.

A tangent took off about moving the scanning in to a proper GCC compiler plugin related to GCC annotations. Colin was a little worried about what would happen when people try to use other languages.

Someone wondered about best-practices for writing an application to be prepared for polyglot programming: for example a game that wants to add a Lua engine for scripting. Colin said that you're 85% of the way there just by using GObject. Other than that, you don't need to do anything else: there's no need to break out in to a shared library.

Sponsored by GNOME Foundation