Re: KDE Interop [Was: D-BUS background] - re-using glib

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-03-05 at 04:53, Michael Meeks wrote:
> Hi Owen,
> 
> On Wed, 2003-03-05 at 03:16, Owen Taylor wrote:
> > > > I am just tired of hearing glib brought up as a problem everytime
> > > > code sharing is discussed because at this point that should be a
> > > > non-issue.
> > > 
> > > GLib in itself is never an issue we can deal with core glib just fine, I 
> > > just don't want any gobject's in core libraries and I think that's a 
> > > reasonable expectation.
> > 
> > It should be pointed out here that one of libgobject's primary goals
> > is to provide standardized memory management (and so forth) so that
> > GObject's can be wrapped in other languages or bridged to other
> > object systems.
> 
> 	There are several points that are interesting here; People have already
> split bits out of glib (libole2 eg.) for use in KDE, and (clearly) a
> common main-loop is a desirable goal with Qt.
> 
> 	It also somewhat worries me that people are adding yet more linked list
> routines to the stack;
> 
> 	Would it not make sense to create a 'K'lib - which re-implemented some
> of the common code, G(S)List, GHashTable, GMain*, GString etc. under an
> X11 license - either using the same symbol names and namespace, 'g_' -
> or simply wrapping / symbol aliasing them inside glib?
>
> 	Then we could have the satisfaction of sharing code / maintenance, not
> having GObject/GType forced on us[1], and perhaps make things more
> efficient.
> 
> 	Probably an orthogonal, and/or distracting issue to D/BUS'
> implementation itself; but an interesting / possible one ?

I think going off in some direction here would be highly premature
without knowing what the exact problems are, and knowing that some
particular course of action would resolve these issues. Objections that
people have had at times to GLib include:
 
 - The abort on out-of-memory policy. But this is presumably not
   an issue for KDE, which has the same thing.

 - The LGPL license. Presumably not an issue for KDE.

 - Dependencies - on some systems GLib can bring in a requirement
   for GNU gettext and libiconv. But I suspect KDE already has
   these dependencies.

 - Runtime overhead of linking to GLib. A mini-glib could address
   this to some extent, if it was mini-enough. But my guess is
   that when you get that small, it's not that useful.

   In reality, most users (but not, perhaps the biggest KDE 
   partisans...) will be running at least one GLib2 app already,
   and at that point, the most useful way to reduce link time
   overhead is actually:

    - _Merge_ libraries. Linking to 4 libraries is distinctly
      more expensive than linking to 1.
    - Aggressively reduce non-lazy relocations (and/or use prelink)

But my guess is that the real reasons are harder to address:

 - A (perhaps even justified) fear of bloat and slowness through longer
   code paths and wrappers.

 - A (perhaps even justified) fear of being forced to program to     
   non-C++-friendly and/or non-Qt-friendly API's.
 
 - One more thing to compile, one more thing to learn.

And probably some generalized GFear and GLoathing.

Regards,
                                             Owen