Date: Mon, 23 Nov 2009 09:08:34 +0200
Message-ID: <87pr79yaz1.wl%djcb@djcbsoftware.nl>
From: Dirk-Jan C. Binnema <djcb.bulk@gmail.com>
To: Carl Worth <cworth@cworth.org>
In-Reply-To: <877htifa0e.fsf@yoom.home.cworth.org>
References: <87aayggsjp.wl%djcb@djcbsoftware.nl>
	<87iqd43wot.fsf@yoom.home.cworth.org>
	<87skc6n3yp.wl%djcb@djcbsoftware.nl>
	<877htifa0e.fsf@yoom.home.cworth.org>
Mail-Reply-To: djcb@djcbsoftware.nl
User-Agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/23.1 Mule/6.0
	(HANACHIRUSATO)
Organization: DJCBSoftware
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: "notmuch@notmuchmail.org" <notmuch@notmuchmail.org>
Subject: Re: [notmuch] interesting project!
Precedence: list
Reply-To: djcb@djcbsoftware.nl

Hi Carl,

>>>>> "Carl" == Carl Worth <cworth@cworth.org> writes:

    Carl> On Sun, 22 Nov 2009 14:23:10 +0200, Dirk-Jan C. Binnema
    Carl> <djcb.bulk@gmail.com> wrote:
    >> A small question: it seems that notmuch is avoiding the use of GLib directly
    >> (of course, it depend on it anyway through GMime); is this because of
    >> OOM-handling? It'd be nice if GLib could be used, it would make some things
    >> quite a bit easier.

    Carl> It's true that I don't like the OOM handling in glib. I also think that
    Carl> glib tries to be too many different things at the same time. And
    Carl> finally, having some talloc-friendly data structures (like a hash-table)
    Carl> would be really nice.

Well, the counter point to the OOM-problems is that is that in many programs,
the 'malloc returns NULL'-case is often not very well tested (because it's
rather hard to test), and that at least on Linux, it's unlikely that malloc
ever does return NULL. Lennart Poettering wrote this up in some more
detail[1]. Of course, the requirements for notmuch may be a bit different and
I definitely don't want to suggest any radical change here after only finding
out about notmuch a few days ago :)

(BTW, there is a hashtable implementation in libc, (hcreate(3) etc.). Is that
one not sufficiently 'talloc-friendly'? It's not very user-friendly, but
that's another matter)

    Carl> In the meantime, as you say, we're already linking with glib because of
    Carl> GMime, so there's really no reason not to call functions that are there
    Carl> and that do what we want. What kinds of things were you thinking of that
    Carl> would be easier with glib?

I could imagine the string functions could replace the ones in talloc. There
are many more string functions, e.g., for handling file names / paths, which
are quite useful. Then there are wrappers for gcc'isms (G_UNLIKELY etc.) that
would make the ones in notmuch unneeded, and a lot of compatibility things
like G_DIR_SEPARATOR. And the datastructures (GSlice/GList/GHashtable) are
nice. The UTF8 functionality might come in handy.

Anyway, I was just curious, people have survived without GLib before, and if
you dislike the OOM-strategy, it's a bit of a no-no of course.

Best wishes,
Dirk.


[1] http://article.gmane.org/gmane.comp.audio.jackit/19998

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C