| 1 | TODO list for agedu |
| 2 | =================== |
| 3 | |
| 4 | Before it's non-embarrassingly releasable: |
| 5 | |
| 6 | - work out what to do about atimes on directories in the absence of |
| 7 | the Linux syscall magic |
| 8 | * one option is to read them during the scan and reinstate them |
| 9 | after each recursion pop. Race-condition prone. |
| 10 | * marking them in a distinctive colour in the reports is another |
| 11 | option. |
| 12 | * a third option is simply to ignore space taken up by |
| 13 | directories in the first place; inaccurate but terribly simple. |
| 14 | * incidentally, sometimes open(...,O_NOATIME) will fail, and |
| 15 | then we have to fall back to ordinary open. Be prepared to do |
| 16 | this, which probably means getting rid of the icky macro |
| 17 | hackery in du.c and turning it into a more sensible run-time |
| 18 | abstraction layer. |
| 19 | |
| 20 | - polish the plain-text output to make it look more like du |
| 21 | + configurable recursive output depth |
| 22 | + show the right bits last |
| 23 | |
| 24 | - cross-Unix portability: |
| 25 | + use autoconf |
| 26 | * configure use of stat64 |
| 27 | * configure use of /proc/net/tcp |
| 28 | * configure use of /dev/random |
| 29 | * configure use of Linux syscall magic replacing readdir |
| 30 | + later glibcs have fdopendir, hooray! So we can use that |
| 31 | too, if it's available and O_NOATIME is too. |
| 32 | * what do we do elsewhere about _GNU_SOURCE? |
| 33 | |
| 34 | - man page, licence, --version. |
| 35 | |
| 36 | Future possibilities: |
| 37 | |
| 38 | - IPv6 support in the HTTP server |
| 39 | * of course, Linux magic auth can still work in this context; we |
| 40 | merely have to be prepared to open one of /proc/net/tcp or |
| 41 | /proc/net/tcp6 as appropriate. |
| 42 | |
| 43 | - run-time configuration in the HTTP server |
| 44 | * I think this probably works by having a configuration form, or |
| 45 | a link pointing to one, somewhere on the report page. If you |
| 46 | want to reconfigure anything, you fill in and submit the form; |
| 47 | the web server receives HTTP GET with parameters and a |
| 48 | referer, adjusts its internal configuration, and returns an |
| 49 | HTTP redirect back to the referring page - which it then |
| 50 | re-renders in accordance with the change. |
| 51 | * All the same options should have their starting states |
| 52 | configurable on the command line too. |
| 53 | |
| 54 | - curses-ish equivalent of the web output |
| 55 | + try using xterm 256-colour mode. Can (n)curses handle that? If |
| 56 | not, try doing it manually. |
| 57 | + I think my current best idea is to bypass ncurses and go |
| 58 | straight to terminfo: generate lines of attribute-interleaved |
| 59 | text and display them, so we only really need the sequences |
| 60 | "go here and display stuff", "scroll up", "scroll down". |
| 61 | + I think the attribute-interleaved text might be possible to do |
| 62 | cunningly, as well: we autodetect a basically VT-style |
| 63 | terminal, and add 256-colour sequences on the end. So, for |
| 64 | instance, we might set ANSI-yellow foreground, set ANSI-red |
| 65 | background, _then_ set both foreground and background to the |
| 66 | appropriate xterm 256-colour, and then display some |
| 67 | appropriate character which would have given the right blend |
| 68 | of the ANSI-16 fore and background colours. Then the same |
| 69 | display code should gracefully degrade in the face of a |
| 70 | terminal which doesn't support xterm-256. |
| 71 | * current best plan is to simulate the xterm-256 shading from |
| 72 | 0/5 to 5/5 by doing space, colon and hash in colour A on |
| 73 | colour B background, then hash, colon and space in B on A |
| 74 | background. |
| 75 | + Infrastructure work before doing any of this would be to split |
| 76 | html.c into two: one part to prepare an abstract data |
| 77 | structure describing an HTML-like report (in particular, all |
| 78 | the index lookups, percentage calculation, vector arithmetic |
| 79 | and line sorting), and another part to generate the literal |
| 80 | HTML. Then the former can be reused to produce very similar |
| 81 | reports in coloured plain text. |
| 82 | |
| 83 | - http://msdn.microsoft.com/en-us/library/ms724290.aspx suggest |
| 84 | modern Windowses support atime-equivalents, so a Windows port is |
| 85 | possible in principle. |
| 86 | + For a full Windows port, would need to modify the current |
| 87 | structure a lot, to abstract away (at least) memory-mapping of |
| 88 | files, details of disk scan procedure, networking for httpd. |
| 89 | Unclear what the right UI would be on Windows, too; |
| 90 | command-line exactly as now might be considered just a |
| 91 | _little_ unfriendly. Or perhaps not. |
| 92 | + Alternatively, a much easier approach would be to write a |
| 93 | Windows version of just the --scan-dump mode, which does a |
| 94 | filesystem scan via the Windows API and generates a valid |
| 95 | agedu dump file on standard output. Then one would simply feed |
| 96 | that over the network connection of one's choice to the rest |
| 97 | of agedu running on Unix as usual. |