TODO list for agedu
===================
-Before it's non-embarrassingly releasable:
+ - adjust the default web server address selection.
+ + some systems (e.g. OS X) don't like us binding to random
+ localhost addresses. So if that fails, try falling back to
+ 127.0.0.1 proper (and a randomly selected port) before giving
+ up.
+ + since binding to port 80 isn't generally feasible, we should
+ adjust the default behaviour when the user specifies --addr
+ with no port: it should select port zero, and then print the
+ port number on standard output. (Possibly also print the URL
+ as usual, in that situation: translate INADDR_ANY to
+ INADDR_LOOPBACK and then do the same as when we made the
+ entire address up ourself.)
- - more flexible running modes
- + at least some ability to chain actions within the same run:
- "agedu -s dirname -w" would seem handy.
+ - we should munmap in all operating modes where we mmapped,
+ otherwise chaining them will run out of address space
- - work out what to do about atimes on directories in the absence of
- the Linux syscall magic
- * one option is to read them during the scan and reinstate them
- after each recursion pop. Race-condition prone.
- * marking them in a distinctive colour in the reports is another
- option.
- * a third option is simply to ignore space taken up by
- directories in the first place; inaccurate but terribly simple.
- * incidentally, sometimes open(...,O_NOATIME) will fail, and
- then we have to fall back to ordinary open. Be prepared to do
- this, which probably means getting rid of the icky macro
- hackery in du.c and turning it into a more sensible run-time
- abstraction layer.
+ - 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.
- - polish the plain-text output to make it look more like du
- + configurable recursive output depth
- + show the right bits last
-
- - cross-Unix portability:
- + use autoconf
- * configure use of stat64
- * configure use of /proc/net/tcp
- * configure use of /dev/random
- * configure use of Linux syscall magic replacing readdir
- + later glibcs have fdopendir, hooray! So we can use that
- too, if it's available and O_NOATIME is too.
- * what do we do elsewhere about _GNU_SOURCE?
-
- - man page, licence.
-
-Future possibilities:
+ - 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.
- IPv6 support in the HTTP server
* of course, Linux magic auth can still work in this context; we
straight to terminfo: generate lines of attribute-interleaved
text and display them, so we only really need the sequences
"go here and display stuff", "scroll up", "scroll down".
- + I think the attribute-interleaved text might be possible to do
- cunningly, as well: we autodetect a basically VT-style
- terminal, and add 256-colour sequences on the end. So, for
- instance, we might set ANSI-yellow foreground, set ANSI-red
- background, _then_ set both foreground and background to the
- appropriate xterm 256-colour, and then display some
- appropriate character which would have given the right blend
- of the ANSI-16 fore and background colours. Then the same
- display code should gracefully degrade in the face of a
- terminal which doesn't support xterm-256.
- * current best plan is to simulate the xterm-256 shading from
- 0/5 to 5/5 by doing space, colon and hash in colour A on
- colour B background, then hash, colon and space in B on A
- background.
+ Infrastructure work before doing any of this would be to split
html.c into two: one part to prepare an abstract data
structure describing an HTML-like report (in particular, all
~mdw / sgt / agedu / blobdiff