TODO list for agedu
===================
-Before it's non-embarrassingly releasable:
-
- - more flexible running modes
- + combined scan+dump mode which doesn't even generate an index
- file (nearly indistinguishable from find(1))
- + load mode which reads a dump from standard input and builds
- the index (need to nail down a perfectly general dump format)
- + at least some ability to chain actions within the same run:
- "agedu -s dirname -w" would seem handy.
-
- - 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.
-
- - polish the plain-text output to make it look more like du
- + configurable recursive output depth
- + show the right bits last
-
- - figure out what to do about scans starting in the root directory
- + Currently we end up with a double leading slash on the
- pathnames, which is ugly, and we also get a zero-length href
- in between those slashes which means the web interface doesn't
- let you click back up to the top level at all.
- + One big problem here is that a lot of the code assumes that
- you can find the extent of a pathname by searching for "foo"
- and "foo^A", trusting that anything inside the directory will
- begin "foo/". So I'd need to consistently fix this everywhere
- so that a trailing slash is disregarded while doing it, but
- not actually removed.
- + The text output gets it all wrong.
- + The HTML output is fiddly even at the design stage: where
- would I _ideally_ put the link to click on to get back to /?
- It's unclear!
-
- - 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?
-
- - prepare a little in advance for a potential future Windows port:
- + store the path separator character in the index file when
- writing it, and load it back in when reading
- + store literal byte sizes in all the size fields, instead of
- Unixoid 512-byte sectors
-
- - man page, licence.
-
-Future directions:
+ - 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.
- IPv6 support in the HTTP server
+ * of course, Linux magic auth can still work in this context; we
+ merely have to be prepared to open one of /proc/net/tcp or
+ /proc/net/tcp6 as appropriate.
- run-time configuration in the HTTP server
* I think this probably works by having a configuration form, or
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
agedu dump file on standard output. Then one would simply feed
that over the network connection of one's choice to the rest
of agedu running on Unix as usual.
+
+ - it might conceivably be useful to support a choice of indexing
+ strategies. The current "continuous index" mechanism' 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 "discrete index" 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.
+ * however, now we have the cut-down version of the continuous
+ index, the space saving is less compelling.