- - integrate more usefully with the output of configure. It's
- generating oodles of automatic boilerplate in config.h and I'm
- sure three quarters of it _ought_ to be usable to add
- portability, if only I had the gumption to actually pay attention
- to all those HAVE_FOO macros it's defined for me.
+ - we should munmap in all operating modes where we mmapped,
+ otherwise chaining them will run out of address space
+
+ - we could still be using more of the information coming from
+ autoconf. Our config.h is defining a whole bunch of HAVE_FOOs for
+ particular functions (e.g. HAVE_INET_NTOA, HAVE_MEMCHR,
+ HAVE_FNMATCH). We could usefully supply alternatives for some of
+ these functions (e.g. cannibalise the PuTTY wildcard matcher for
+ use in the absence of fnmatch, switch to vanilla truncate() in
+ the absence of ftruncate); where we don't have alternative code,
+ it would perhaps be polite to throw an error at configure time
+ rather than allowing the subsequent build to fail.
+ + however, I don't see anything here that looks very
+ controversial; IIRC it's all in POSIX, for one thing. So more
+ likely this should simply wait until somebody complains.
+
+ - it would be useful to support a choice of indexing strategies.
+ The current system's tradeoff of taking O(N log N) space in order
+ to be able to support any age cutoff you like is not going to be
+ ideal for everybody. A second more conventional mechanism which
+ allows the user to specify a number of fixed cutoffs and just
+ indexes each directory on those alone would undoubtedly be a
+ useful thing for large-scale users. This will require
+ considerable thought about how to make the indexers pluggable at
+ both index-generation time and query time.