From: simon Date: Tue, 23 Feb 2010 22:34:32 +0000 (+0000) Subject: TODO updates. X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/agedu/commitdiff_plain/25b6ba22691ab8853eab55787eb878cd850f4371 TODO updates. git-svn-id: svn://svn.tartarus.org/sgt/agedu@8884 cda61777-01e9-0310-a592-d414129be87e --- diff --git a/TODO b/TODO index f8c723d..4220a4d 100644 --- a/TODO +++ b/TODO @@ -1,6 +1,13 @@ TODO list for agedu =================== + - flexibility in the HTML report output mode: expose the internal + mechanism for configuring the output filenames, and allow the + user to request individual files with hyperlinks as if the other + files existed. (In particular, functionality of this kind would + enable other modes of use like the built-in --cgi mode, without + me having to anticipate them in detail.) + - 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, @@ -45,26 +52,16 @@ TODO list for agedu HTML. Then the former can be reused to produce very similar reports in coloured plain text. - - 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. + - abstracting away all the Unix calls so as to enable a full + Windows port. We can already do the difficult bit on Windows + (scanning the filesystem and retrieving atime-analogues). + Everything else is just coding - albeit quite a _lot_ of coding, + since the Unix assumptions are woven quite tightly into the + current code. + + If nothing else, it's unclear what the user interface properly + ought to be in a Windows port of agedu. A command-line job + exactly like the Unix version might be useful to some people, + but would certainly be strange and confusing to others. - it might conceivably be useful to support a choice of indexing strategies. The current "continuous index" mechanism' tradeoff of @@ -78,3 +75,19 @@ TODO list for agedu and query time. * however, now we have the cut-down version of the continuous index, the space saving is less compelling. + + - A user requested what's essentially a VFS layer: given multiple + index files and a map of how they fit into an overall namespace, + we should be able to construct the right answers for any query + about the resulting aggregated hierarchy by doing at most + O(number of indexes * normal number of queries) work. + + - Support for filtering the scan by ownership and permissions. The + index data structure can't handle this, so we can't build a + single index file admitting multiple subset views; but a user + suggested that the scan phase could record information about + ownership and permissions in the dump file, and then the indexing + phase could filter down to a particular sub-view - which would at + least allow the construction of various subset indices from one + dump file, without having to redo the full disk scan which is the + most time-consuming part of all.