- - cross-module:
- + 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!
-
- - more flexible running modes
- + decouple the disk scan from the index building code, so that
- the former can optionally output in the same format as --dump
- and the latter can optionally work from input on stdin (having
- also fixed the --dump format in the process so it's perfectly
- general). Then we could scan on one machine and transfer the
- results over the net to another machine where they'd be
- indexed; in particular, this way the indexing machine could be
- 64-bit even if the machine owning the filesystems was only 32.
- + ability to build a database _and_ immediately run one of the
- ongoing interactive report modes (httpd, curses) would seem
- handy.
+ - http://msdn.microsoft.com/en-us/library/ms724290.aspx suggest
+ modern Windowses support atime-equivalents, so a Windows port is
+ 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.
+ * Disk scan procedure: the FindFirstFile / FindNextFile
+ functions to scan a directory automatically return the file
+ times along with the filenames, so there's no need to stat
+ them later. Would want to fiddle the shape of the
+ abstraction layer to reflect this.
+ + 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.