Hi, We think GObject Introspection adds a lot to the GNOME platform and would like to discuss how it can be integrated.
For background, there's a longer description of what introspection does here: http://live.gnome.org/GObjectIntrospection >From a component perspective, the major moving parts are: * 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 _______________________________________________ language-bindings mailing list [email protected] http://mail.gnome.org/mailman/listinfo/language-bindings
