My WWW-Authenticate header should end with \r\n like all the others,

[sgt/agedu] / TODO

diff --git a/TODO b/TODO
index e742e4b..c11cd11 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,24 +1,18 @@
 TODO list for agedu
 ===================
 
-Before it's non-embarrassingly releasable:
-
- - arrange to be able to identify directories and leave them on one
-   side of the usual age display
-
- - 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, --version.
-
-Future possibilities:
+ - 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
@@ -66,3 +60,16 @@ Future possibilities:
       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.