TODO list for agedu
===================

Before it's non-embarrassingly releasable:

 - sort out the command line syntax
    * I think there should be a unified --mode / -M for every
      running mode, possibly without the one-letter option for the
      diagnostic sorts of things
    * there should be some configurable options: 
       + range limits on the age display
       + server address in httpd mode
       + HTTP authentication: specify username and/or password, the
	 latter by at least some means which doesn't involve it
	 showing up in "ps"

 - 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.

 - make a final decision on the name!

 - man page, licence, online help.

Future directions:

 - run-time configuration in the HTTP server
    * I think this probably works by having a configuration form, or
      a link pointing to one, somewhere on the report page. If you
      want to reconfigure anything, you fill in and submit the form;
      the web server receives HTTP GET with parameters and a
      referer, adjusts its internal configuration, and returns an
      HTTP redirect back to the referring page - which it then
      re-renders in accordance with the change.
    * All the same options should have their starting states
      configurable on the command line too.

 - polish the plain-text output:
    + do the same formatting as in HTML, by showing files as a
      single unit and also sorting by size? (Probably the other way
      up, due to scrolling.)
    + configurable recursive output depth

 - curses-ish equivalent of the web output
    + try using xterm 256-colour mode. Can (n)curses handle that? If
      not, try doing it manually.

 - cross-module:
    + 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!

 - more flexible running modes
    + decouple the disk scan from the index building code, so that
      the former can optionally output in the same format as --dump
      and the latter can optionally work from input on stdin (having
      also fixed the --dump format in the process so it's perfectly
      general). Then we could scan on one machine and transfer the
      results over the net to another machine where they'd be
      indexed; in particular, this way the indexing machine could be
      64-bit even if the machine owning the filesystems was only 32.
    + in the other direction, ability to build a database _and_
      immediately run one of the ongoing interactive report modes
      (httpd, curses) in a single invocation would seem handy.

 - portability
    + between Unices:
       * 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?
    + http://msdn.microsoft.com/en-us/library/ms724290.aspx suggest
      modern Windowses support atime-equivalents, so a Windows port
      is possible in principle. Would need to modify the current
      structure a lot, to abstract away (at least) memory-mapping of
      files, details of disk scan procedure, networking for httpd,
      the path separator character (yuck). Unclear what the right UI
      would be on Windows, too; command-line exactly as now might be
      considered just a _little_ unfriendly. Or perhaps not.