1 -*- text -*- 2Bugs: 3 4- "sitecopy foo bar" always process foo and bar in the order they 5 are specified in the rcfile 6 7- review w.r.t djb's FTP interop notes, http://cr.yp.to/ftp.html 8 9- add support for MLST, latest draft: 10 http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt 11 12- enable large file support by default when necessary. 13 14- Synch mode won't transfer in ASCII mode, nor maintain symlinks, nor 15 correctly order file deletions. 16- Filename conflicts are not handled by update or synch mode: case: 17 Directory exists remote called "foo". Delete locally, replace with 18 file called "foo". Try an update. Bang. Another nice one is: 19 mv foo tmp 20 mv bar foo 21 mv tmp bar 22 Which, in renames mode, will be correctly discovered, but when we 23 do an --update... bang. 24- "sitecopy --rcfile=/" should say the right thing 25- The man page does not make clear what "exclude" excludes *from*. 26 The point that exclude will translate into deleting existing files 27 from the remote site is important and confusing. 28 29Known Standards Compliance Problems: 30 31- RFC959: handle telnet control characters? 32- RFC2518: accept collection URI's in DAV:href without trailing slash 33- RFC2617: support 'domain' 34 35* anything with (FEAPI) after requires frontend API change, not including 36 simple config options additions 37 38- Move use_this out of struct site, use proper data structures in console 39 frontend to represent sites passed on cmd line. 40- Anything in the below list. 41- Do the hash table thang. 42 43Required Features for one-point-oh: 44 45- Verify mode, also a --force-overwrite to force updates... maybe 46 --prompt-overwrite too. 47- Filename conflict resolution for update mode, as per bug... or at LEAST, 48 conflict detection: can be done in file_set, not too hard probably. 49- Read HTTP proxy from HTTP_PROXY/http_proxy environment variable. 50- Document files list order dependancies. 51- Do default ports, netrc lookups for the proxy too 52- Report corrupt info files back to the user (FEAPI) 53- Check write return codes in site_writefiles, signal the error if 54 the info file doesn't get written properly. 55- Get warning (i.e. non-fatal) messages to the user. 56- Check remote directory exists on initial connection in FTP (chdir/ls) 57- In davdriver.c:dir_remove, check whether the collection is empty before 58 deleting it. 59- Because it's The Right Thing, add hash table indexing of files list. 60 Hash using DJBs *33 hash algorithm. Open hash so we don't have 61 worry about filling the table up. Size the hash table in the range 62 100kB-200kB to not give too much run-time bloat, but not to fill up 63 with reasonable-sized sites too quickly. Maybe do a user survey to determine 64 optimum hash-table size. 65- "include" option to mirror "exclude". 66 67"Would be Nice to Have But We Can Live Without" features: 68 69- "sftp" support; FTP-over-SSL 70- Console: don't read local site state in --fetch mode. 71- Support FTP proxying (how?): there are several different ways this is done... 72- Support for Content-MD5 header and allow server-side MD5'ing, rather 73 than having to download, checksum and discard. (remote-checksum) 74- Symlink 'maintain' mode for FTP: can you create symlinks over FTP??? 75- Write complete documentation using GNU texinfo or DocBook, for a 76 printed manual and info pages. 77 78Possible features, which need more consideration: 79 80- Per-site lockfiles (FEAPI) 81- Shortcircuit parm in file_set_* used for the FIRST site state read on a 82 site, to make the file search always fail - guarantee to be true, since if we 83 read local state before stored state, there is no stored state in the 84 list when we read the local state. 85- Console: Some kind of 'first-time-use' option, `sitecopy --first-time' 86 runs a wizard a la the GNOME fe's one. 87- Support for other better/faster checksumming algorithms: is SHA1 88 better/faster? (GPL implementation in GnuPG) 89- Backup info file on write_stored... optionally? Only implement in frontend? 90 GNU-style $VERSION_CONTROL support? 91- Have 'preconnect' and 'postconnect' options which run user-specified 92 programs before and after an update, synch etc. 93- Some kind of user-feedback for slow startup in checksumming mode. 94 takes approx 1 sec to MD5 a 10mb file on a K5 166 -> okay for average-sized 95 sites. (FEAPI)... 96- Abstract protocol drivers into a mc VFS-like 'open', 'read' etc. 97 Abstract sites code so that "local" and "remote" can be handled by any 98 of {file, http, ftp}. Then, update + synch could possibly merge, since 99 an synch is an update with the remote and local sides switched (kindof). 100- Allow file->file sites (screem wants this)... as above, or simply by 101 implementing another protocol driver. 102- consequently, read ls-laR.txt files and be more like 'mirror' 103- Add quota management, specify a per-site quota and only do update 104 if the result means the site will stay under quota. 105 -> problem: a directory uses up k's, but how many? 106- Abstract protocol drivers into a mc VFS-like 'open', 'read' etc. 107 Abstract sites code so that "local" and "remote" can be handled by any 108 of {file, http, ftp}. Allows file->file sites, which screem wants. 109- Read ls-laR.txt files and be more like 'mirror' 110 111Evaluation of sitecopy alternatives: weex 112 113- weex beats sitecopy hands-down in new user ease-of-use: you just run it. 114 With sitecopy you have to do --fetch or --catchup first. This situation 115 is slightly improved in 0.9, where on the first 'sitecopy newsite' 116 invocation, you get told what to do next. 117- sitecopy could improve by doing: 118 an interactive 'on first run for site', like the GNOME fe site 119 creation wizard. This could create the .sitecopy directory with the 120 correct permissions (but I am a bit dubious about this). 121- Another alternative is the --first-time option. This could do: 122 mkdir .sitecopy with correct perms 123 create .sitecopyrc with correct perms 124 ? enter a complete site definition, and run --init, or --fetch, 125 or catchup, as appropriate. 126 This could either be run automagically if no .sitecopyrc file is 127 found (don't let trigger by --rcfile= option), or, better, by a message 128 telling you to run --first-time. 129 --new-user might be better... 130 131Definitely Not-till-after-1.0 thinkings: 132 133The current "file list" is bad. It is pseudo-sorted by depth (probably). 134The GNOME fe wants a proper directory tree representation. 135 136To allow the possibility of doing the "spot moved directories" test, 137we might want a proper dirtree; but, this is a complex task, and might 138be achieved in another way. 139 140To get decent "checkmoved" operation, need better than O(n) lookup. 141O(1)-ish could be achieved using a a hash table. 142 143- Find operation on the files list is O(n), making state reads O(n^2). 144 Hashing would be nice -> can use the MD5 csum. 145 146- Intelligent file movement detector, to spot whole moved directories: 147 Possibly implement by checksumming relative filenames for EACH 148 directory (fairly nasty overhead); so each directory has a 149 children_checksum field. Need a clever checksumming algo; MD5 would 150 require identical ordering, which would be a heavy constraint. 151- Make the protocol drivers and sites code thread-safe. 152 153Things You Might Like to Do On A Rainy Day: 154 155- Investigate any extra handling needed for servers which have case 156 insensitive filenames 157- Native Windows port (e.g. reimplement socket.c using the Winsock API) 158- Convince the maintainer that it's more productive to spend time 159 implementing features than carefully crafting a mile-long TODO list. 160 161XSitecopy TODO 162-------------- 163 164- Tooltip(s) for the site widgets; specifically safe mode. 165- Integrating resynch into the app. 166- View files using gnome mime types. 167- Transition from time-size to checksum. 168* Prefs 169 170Future releases: 171 172- Bring back optional 'slim' mode which will take up less desktop real estate. 173- Popup menus for the site/file tree. 174- Single file updates. 175- Update all. 176 177Longer term things: 178 179- Panel applet for easily updating sites in a couple of clicks. 180- Html based reports - integration into FE apps, and possible auto uploading 181 to the remote site. (useful as a "recent changes" page) 182* Please send any suggestions you may have as to the format/design/type of 183 reports that you might find useful. 184