Re: is glib too bloated?

[Brandon Casey <casey nrlssc navy mil>]

On Mon, 23 Apr 2007, Emmanuele Bassi wrote:
> On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote:
> > On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote:
> > > I am posting to suggest that glib has crossed a threshold
> > > of size and functionality and that users would benefit from
> > > a splitting of the library into two or more separate libraries.
> >
> > For the record, I dont think glib is oversized or bloated at
> > all, I dont think its size is even a concern worth considering
> > even in embedded world, that being said...
>
> for my experience, you're right: even GTK+ is not "bloated" in that
> respect. I've seen my share of compressed filesystem images containing
> the whole stack from X up to GStreamer in ~16MB, so everything could be
> said about GLib but it being "bloated".

There is nothing implemented in GLib that is not useful in some way to
the GTK+ stack. So I agree that the functionality is not bloat.

I only suggest that the inclusion of some of this functionality in GLib
has increased the scope of GLib. It's no secret that GLib-2 is <cowers>
4 times larger than GLib-1. The absolute number is still fairly small,
but the change in size indicates that there is 4 times as much stuff in
GLib-2. I suspect that a lot of the increase in size is due to i18n
efforts in dealing with strings. And this has caused the dependency
requirements of glib to grow, which makes it harder to build (think non
linux platforms).

I think there are developers out there who would benefit from a
narrowing of the scope of glib, so that it only contains "base" data
structures and functionality (yeah I know, define "base"). And move
the more higher level functionality into another library.

-brandon