is glib too bloated?

[Brandon Casey <casey nrlssc navy mil>]

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.

In my opinion, it is exceeding its stated purpose as a
"low-level core library"... "provid[ing] data structure handling
for C, portability wrappers, and" a few other things that should
or should not be included.

Has any thought been given to splitting glib into two libraries?

  The first which would contain all the data structure stuff like
  linked lists, hash tables, binary trees, arrays, all the gint,
  gint32, etc, and portability macros. I suggest that this portion
  of the library retain the glib.

  The second would be a new library built on top of glib taking
  over anything not considered "core", such as xml parsers, unicode
  handling, and anything that depends on them.

The core data structures that glib provides are excellent
implementations of well known and often used functionality.
The same goes for the portability macros.

The growth in size and in dependencies is making it difficult
to compile glib on non linux platforms. It is regrettable
that some software projects have to avoid glib because of this,
and then re-invent the wheel when glib has a well tested, stable
and secure version.

-brandon