[no subject]

* Source comment (gtk-doc) annotations we expect C authors to
  use and maintain in libraries
* C source code scanner for extracting the C API merged with
   the annotations
* An XML-based representation of this data (GIR) suitable
  for build-time tools to process (e.g. gtk-doc)
* An mmap()able binary on-disk format (typelib) suitable
  for applications and runtime bindings to consume
* A shared library (libgirepository) for accessing the introspection
  in runtime

On top of GObject Introspection, bindings such as
seed/gjs/Vala/JGIR/sbank etc. have been written.
Besides the binding and application usage, it would make sense to use
introspection inside GTK+ itself (GtkBuilder for instance)

What we'd like to discuss is how exactly introspection should be integrated
into the platform. One thing to keep in mind is that the introspection design
requires that we become a build dependency of every library providing
an introspectable API.

== Option 1: Included in glib.tar.gz, included in libgobject-2.0.so ==

This should be technically possible.  We would add two header files:
http://git.gnome.org/cgit/gobject-introspection/tree/girepository/girepository.h
http://git.gnome.org/cgit/gobject-introspection/tree/girepository/girffi.h
On x86_64 stripped, the code is 75k, or ~25% of libgobject size.
This would likely be smaller when actually integrated (Don't know
offhand about the constants involved in ELF file sizes).

Part of libgirepository only used at build time depends on gio, so
we'd need to split that out into a separate library, or we could
rewrite it to not have that dependency.

There are obviously high compatibility, documentation, etc. expectations
when being included in GLib, and though we have remaining work to do we
believe that we could meet this.

One advantage of being integrated into GObject is that with some nontrivial
work, We believe that we could actually replace parts of the runtime
GType system with introspection, which would be a win because we'd
be removing all the runtime allocation that GType does and replacing it
with access to the mmap()ed typelib.

PRO: First class citizen, you'd always get everything introspectable
PRO: Reduced footprint for introspected libraries, it'll always there and used
CON: More work, would take longer time to integrate
CON: Tied to the GObject development process
CON: Increased GObject library size

== Option 2: Included in glib.tar.gz, as a separate libgirepository-1.0.so ==

This is a model like Gio and the proposed eggdbus one, adding another
shared library, pkg-config file etc.

PRO: No major changes to GObject, thus no possibility of disruption
PRO: Clear separation of layers and responsibility
CON: Separate library causes more linking overhead
CON: No possibility to optimize GObject itself and remove redundancies
  with introspection

== Option 3: Separate module ==

This one has the fewest requirements on introspection, but keep in mind
that another module dependency would be introduced below pango, which
is below most everything in the stack from GTK+ to Clutter.
GObject Introspection would of course have to stick to the platform
requirements in terms of API/ABI stability, release schedule etc.

PRO: Least amount of work of the 3 options
PRO: Development process would be separate, leave more control to the
introspection team
CON: Additional dependency for all libraries in the stack

Colin Walters & Johan Dahlin