Wow. I received the new 2.0b9 texpire.c from Cornelius in advance (with
Stefan's code; I asked for it), and while at a first glance it looks
elaborate, it shows one of the major problems leafnode currently suffers
from.
In various places, throughout leafnode, we encounter several structures,
unbalanced binary trees, qsort-sorted arrays, hash function for
message-ids, hash function for threads (might be mistaken here, did not
look close); one place uses read/open UNIX-level unbuffered I/O, another
place uses stdio buffered functions, ... you name it.
(Don't mistake this as texpire criticism, it applies to leafnode as a
whole.)
It's this scattering and duplication of code which should be
avoided. Rather than having specialized tree functions in various
places, we should consider getting one good implementation for a data
structure, possibly as external library if the license conditions suit
us, to keep the whole thing maintainable. Multiple implementations of a
structure are no good, and a re-implementation of a good library
function such as bsearch is neither.
--
Matthias Andree
--
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list