Introspection binary format comments

[Owen Taylor <otaylor redhat com>]

I mentioned many of these to Matthias in person, but for the benefit
of posterity and others who are interested:

 - Terminology needs some work. I don't think 'interface' can be
   used for the things stored in 'entries', since that's confusing
   with GInterface.

 - Does the format need hash tables in strategic spots to avoid
   linear scans with strcmp() to find particular interfaces or
   methods?

 - Does it actually need to be specified where the string pool
   is in the metadata blob? Can't we just let people writing
   the blob put the strings where they want?

 - It seems to me that we might want to use URL's instead of
   short prefixes to uniquely identify namespaces.

    http://pango.org/api/1.0/

   We then could provide a short name for the namespace 'Pango'
   in addition. This should avoid problems if two libraries on
   the same system not used together use the same short namespace
   and also deals with libraries with multiple major versions.

 - Are we really confident that the type information for a 
   metadata blob will fit into 64k? Creating a metadata blob
   for GTK+ probably will give us an answer for that ... if   
   it's less than 32k, we are probably OK for just about
   any conceivable library.

 - I don't really like packing all GType registered stuff
   into GInterfaceBlob. It seems to me that it should
   be split up - while there is a lot commonality, there
   are also a lot of differences. A common substructure
   could be used to encapsulate the shared part.

   Also, it seems to me that stuff that isn't inherently
   associated with a GType (enums, flags, boxed) should
   have the GType as an optional part. So, the difference
   between StructBlob and BoxedBlob could go away.

 - For virtual functions, structure fields, boxed fields
   finding offsets requires walking over the lists of fields 
   and applying architecture dependent knowledge of struct
   packing. Would it be better to just include the struct
   offset into the metadata blob?

   This would also allow us to omit private and reserved
   fields from the data without compromising the ability
   to find struct offsets.

 - For ArgBlob, the use of receiver_owns_value for both in and
   out is strange. We do forbid the in case in our APIs, but if
   you want to allow that, maybe transfer_ownership would be
   a better name.

 - For ArgBlob, probably need a way to indicate that for out
   parameters, NULL can be passed to mean "don't store"

 - For SignalBlob, do we need a representation of collector
   behavior? Generally this is impossible, but knowing when 
   something is true-stops-emit might be useful.

 - FieldBlob uses SimpleTypeBlob. Could we have fields that
   are arrays or lists?

 - Do we need information about memory management for 
   FieldBlob ... if I replace the value, do I need to free
   the old one? Or do we restrict FieldBlob to things that
   don't need memory management. (Think GtkTargetEntry
   which has a string...)

 - Do all StructBlob types have constructors? Or, do we
   want to support construction on the heap for things like
   GdkRectangle or GtkTargetEntry?