70322ae3 |
1 | TODO list for agedu |
2 | =================== |
3 | |
25b6ba22 |
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.) |
10 | |
652a3712 |
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. |
16 | |
50e82fdc |
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. |
29 | |
1e8d78b9 |
30 | - IPv6 support in the HTTP server |
cfe942fb |
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. |
1e8d78b9 |
34 | |
70322ae3 |
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. |
45 | |
70322ae3 |
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. |
f2e52893 |
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". |
f2e52893 |
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. |
70322ae3 |
60 | |
25b6ba22 |
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 |
66 | current code. |
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. |
14601b5d |
71 | |
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 |
81 | and query time. |
82 | * however, now we have the cut-down version of the continuous |
522edd92 |
83 | index, the space saving is less compelling. |
25b6ba22 |
84 | |
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. |
90 | |
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. |