GLib debate

[Owen Taylor]

I really don't think this debate is going anywhere productive;
I'll make a few observations and suggest we let the topic
lie for now; there is a lot of progress to be made with
less controversial issues.

 - Clearly some people have (perhaps irrational) objections to
   GLib; we've accomodated that in the past, we'll have to 
   continue doing that for libraries we want to have the
   widest possible acceptance.
  
   On the other hand, if people writing a facility think they
   can make their facility more compelling by using GLib
   instead of reinventing the wheel, they should be free
   to balance that against the downsides of discouraging
   some users. 

   Using GLib in a library certainly shouldn't be considered 
   *worse* than making your library 400k bigger by any other means.
   (Like including your own copies of the Unicode tables,
   which are a good fraction of GLib's size)

 - There *are* certainly legitimate reasons to avoid GLib
   for some tasks. One of the primary ones is that (like
   Qt) it doesn't generally allow for recovery from 
   out of memory conditions.

 - Making GLib part of the "freedesktop.org distribution",
   is a separate issue from using it in freedesktop.org
   distributed libraries. GLib is currently used in
   some utilities hosted on gnome.org, and can indeed
   make writing such a utility much easier.

   While I'll stay neutral on the issue of using GLib 
   in libraries, I will say that I think having GLib
   as part of the freedesktop.org distribution, perhaps
   "by reference" (like freetype, libpng, etc) would
   be a neat thing.

   But that's really up to the release team to decide.
   
 - When building APIs, the GLib data structures aren't particularly
   useful; there is no reason to stick a GList into a prototype
   in most cases.
  
   What *is* actually extremely useful is the abstractions in
   GObject; having standard memory management places, ways
   to attach external data, ways of doing callbacks, etc,
   is a huge win, particularly because it makes connecting
   a library to language bindings much easier.

   It's actually much easier to connect a library using GObject
   to C++ than an library that rolls everything by hand.
   This, and the Unicode tables, are the primary reasons
   that Pango uses GObject.

   But I doubt I'd manage to convince anybody who has't 
   actually had a fair amount of experience with GObject 
   of that.

Regards,
					Owen

[ To make the disclosure obvious, I'm one of the maintainers
  of GLIb ]