4 - flexibility in the HTML report output mode: expose the internal
5 mechanism for configuring the output filenames, and allow the
6 user to request individual files with hyperlinks as if the other
7 files existed. (In particular, functionality of this kind would
8 enable other modes of use like the built-in --cgi mode, without
9 me having to anticipate them in detail.)
11 - add the option (and perhaps even make it default) to address HTML
12 subpages by pathname rather than by index number. More than just
13 cosmetic: it means that in a scenario where agedu --cgi is always
14 running but the index file is updated by cron, subsidiary
15 pathnames will remain valid across a change.
17 - we could still be using more of the information coming from
18 autoconf. Our config.h is defining a whole bunch of HAVE_FOOs for
19 particular functions (e.g. HAVE_INET_NTOA, HAVE_MEMCHR,
20 HAVE_FNMATCH). We could usefully supply alternatives for some of
21 these functions (e.g. cannibalise the PuTTY wildcard matcher for
22 use in the absence of fnmatch, switch to vanilla truncate() in
23 the absence of ftruncate); where we don't have alternative code,
24 it would perhaps be polite to throw an error at configure time
25 rather than allowing the subsequent build to fail.
26 + however, I don't see anything here that looks very
27 controversial; IIRC it's all in POSIX, for one thing. So more
28 likely this should simply wait until somebody complains.
30 - IPv6 support in the HTTP server
31 * of course, Linux magic auth can still work in this context; we
32 merely have to be prepared to open one of /proc/net/tcp or
33 /proc/net/tcp6 as appropriate.
35 - run-time configuration in the HTTP server
36 * I think this probably works by having a configuration form, or
37 a link pointing to one, somewhere on the report page. If you
38 want to reconfigure anything, you fill in and submit the form;
39 the web server receives HTTP GET with parameters and a
40 referer, adjusts its internal configuration, and returns an
41 HTTP redirect back to the referring page - which it then
42 re-renders in accordance with the change.
43 * All the same options should have their starting states
44 configurable on the command line too.
46 - curses-ish equivalent of the web output
47 + try using xterm 256-colour mode. Can (n)curses handle that? If
48 not, try doing it manually.
49 + I think my current best idea is to bypass ncurses and go
50 straight to terminfo: generate lines of attribute-interleaved
51 text and display them, so we only really need the sequences
52 "go here and display stuff", "scroll up", "scroll down".
53 + Infrastructure work before doing any of this would be to split
54 html.c into two: one part to prepare an abstract data
55 structure describing an HTML-like report (in particular, all
56 the index lookups, percentage calculation, vector arithmetic
57 and line sorting), and another part to generate the literal
58 HTML. Then the former can be reused to produce very similar
59 reports in coloured plain text.
61 - abstracting away all the Unix calls so as to enable a full
62 Windows port. We can already do the difficult bit on Windows
63 (scanning the filesystem and retrieving atime-analogues).
64 Everything else is just coding - albeit quite a _lot_ of coding,
65 since the Unix assumptions are woven quite tightly into the
67 + If nothing else, it's unclear what the user interface properly
68 ought to be in a Windows port of agedu. A command-line job
69 exactly like the Unix version might be useful to some people,
70 but would certainly be strange and confusing to others.
72 - it might conceivably be useful to support a choice of indexing
73 strategies. The current "continuous index" mechanism' tradeoff of
74 taking O(N log N) space in order to be able to support any age
75 cutoff you like is not going to be ideal for everybody. A second
76 more conventional "discrete index" mechanism which allows the
77 user to specify a number of fixed cutoffs and just indexes each
78 directory on those alone would undoubtedly be a useful thing for
79 large-scale users. This will require considerable thought about
80 how to make the indexers pluggable at both index-generation time
82 * however, now we have the cut-down version of the continuous
83 index, the space saving is less compelling.
85 - A user requested what's essentially a VFS layer: given multiple
86 index files and a map of how they fit into an overall namespace,
87 we should be able to construct the right answers for any query
88 about the resulting aggregated hierarchy by doing at most
89 O(number of indexes * normal number of queries) work.
91 - Support for filtering the scan by ownership and permissions. The
92 index data structure can't handle this, so we can't build a
93 single index file admitting multiple subset views; but a user
94 suggested that the scan phase could record information about
95 ownership and permissions in the dump file, and then the indexing
96 phase could filter down to a particular sub-view - which would at
97 least allow the construction of various subset indices from one
98 dump file, without having to redo the full disk scan which is the
99 most time-consuming part of all.
~mdw / sgt / agedu / blob