HAL 0.1 release

[Havoc Pennington]

On Wed, 2003-10-01 at 18:16, Joe Shaw wrote:
> The two main things I can think of are handling out-of-memory conditions
> and not being tied to a specific main loop.  Otherwise, why did you
> write those routines for dbus instead of just using glib?  I suspect
> many of the same reasons apply.

Basically D-BUS has a small chunk of utility code that is necessary, and
no "extra baggage" that might offend anybody. This also lets it have the
handle-OOM and the always-use-string-class-instead-of-string.h things.
This way you only have to sell people on D-BUS, rather than on D-BUS
plus some dependencies.

If you break the utility library out, then someone has to maintain the
ABI/API (which is not that great right now), and it starts to grow since
it's general-purpose and not just "the little bits of things D-BUS
itself uses." The logical conclusion of that, 5 years down the road,
really has to become a GLib-equivalent library I would think.

> I don't think they're really *that* generally useful, but there are a
> lot of similar problems being solved between dbus and hal (a system
> daemon, a desktop-agnostic library).

Oh for sure, hal is going to have a lot of the same needs. The main loop
integration stuff is doubtless almost identical (including the GLib/Qt
wrapper portions of it).

Maybe we can do something with "automated cut and paste" sort of hacks
(have a script that copies in latest cut-and-paste code from some
canonical source, like update-from-egg.sh in gnome-terminal).

Havoc