exposing the portability layer

[Havoc Pennington]

On Wed, May 28, 2003 at 05:46:34PM -0400, Colin Walters wrote:
> So I'm working on a D-BUS using project, and just like pretty much any
> other C project, I have need of stuff like hash tables, linked lists, a
> nice string library, etc.  D-BUS has all this stuff, but it's not
> exposed to users of the library.
> 
> Since I want this project to be very widely adopted (much like D-BUS
> itself), I'd prefer to avoid even a dependency on glib.
> 
> So what do you guys think about exposing the portability layer in a
> special header?  It would tie applications using it pretty closely to
> D-BUS, but that's not a problem for me.

I don't really want to support that ABI; bits of it kind of suck
and/or may change. For example the global thread locks on the linked
list nodes are definitely in the profile for a multithreaded app, and 
fixing that would break the ABI.

Or just the fact that right now we can drop this stuff from the dbus
lib whenever dbus itself isn't using it, thus keeping down bloat; in
fact various util functions are already inside #ifdef DBUS_BUILD_TESTS

More philosophically, this API would be the same thing as GLib - does
it make sense to use a GLib equivalent that just starts with the dbus_
prefix instead, in order to to avoid a GLib dependency? How is the
dbus_ dependency different? It seems pretty strange from a technical
standpoint.

Even more philosophically, my general feeling is that each library
should have a clear functional purpose and should export only the API
that matches said purpose. Otherwise you get a mess.

Technically speaking, having a single utility layer shared by various
stuff is right; GLib is the only real contender there. The D-BUS util
stuff is ad hoc and fairly lame by comparison. Its only advantage is 
that it handles out-of-memory, but for most apps that's a
disadvantage, really.

Dependencies suck a bit, cut-and-paste code sucks a bit, it's a fact
of life that you always have to choose one or the other. ;-)

Havoc