X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/agedu/blobdiff_plain/1e8d78b987550c351f47b204d3c9649cc1872e45..5a29503dccf98dc8f549d682f543f65d7648869e:/TODO

diff --git a/TODO b/TODO
index 9b93ca2..25b4fd2 100644
--- a/TODO
+++ b/TODO
@@ -3,14 +3,6 @@ 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
@@ -25,26 +17,6 @@ Before it's non-embarrassingly releasable:
       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
@@ -55,17 +27,14 @@ Before it's non-embarrassingly releasable:
 	    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 separator character in the index file when writing
-      it, and be prepared to cope on reading if it isn't a slash
-    + store literal byte sizes in all the size fields, instead of
-      Unixoid 512-byte sectors
-
- - man page, licence.
+ - man page, --version.
 
-Future directions:
+Future possibilities:
 
  - 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
@@ -109,9 +78,16 @@ Future directions:
 
  - 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. 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.
+   possible in principle.
+    + For a full Windows port, 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.
+      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.
+    + Alternatively, a much easier approach would be to write a
+      Windows version of just the --scan-dump mode, which does a
+      filesystem scan via the Windows API and generates a valid
+      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.