Matthias Andree <ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de>:
What code? uid.c, you mean? Needs to be rewritten from scratch, with
clean interfaces. Oh, and rbtree (from Damian Ivereigh, on SourceForge,
LGPL) should be merged when that happens because linear lists are
snails.
If you think you can fix uid.c, you're welcome to try. Every time I touch
it something breaks, so I don't do that anymore. Nor do I trust it.
I know all about redblack, BTW. Close to a year ago I showed Damian that
it should be implemented as a baby code generator rather than a library.
He agreed this was a better approach (it avoids a level of indirection and
ugly hacks with void pointers; also, you get to compile in the comparison
function for better performance), but he hasn't done a release since then.
I wonder on the "traffic" issue if fetchmail should keep a record of
UIDs from failed mail and set a steadily increasing fetch interval for
these that is clamped at 24hrs or 50 runs, whichever comes first.
And with this, you just damaged your chances of moving to
all-UIDLs-all-the-time. Design proposals that increase the amount of
persistent, fragile state that fetchmail has to track make me
break out in hives.
In how far is .fetchids fragile? With all that "saved lists" shuffling,
it indeed is unmaintainable in the shape it's in now.
.fetchids is close to my limit for this sort of thing. This second
set of records with magic timeouts goes way over it.
The easy approach to make the stuff robust is split this up per account
and server and keep it in a ~/.fetchmail directory, and to make sure
it's never overwritten, but replaced atomically (write .new file, rename
into place).
That would be more sensible, yes.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>