"Fossies" - the Fresh Open Source Software Archive

Member "sitecopy-0.16.6/TODO" (4 Feb 2006, 8179 Bytes) of archive /linux/www/sitecopy-0.16.6.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 						-*- text -*-
    2 Bugs:
    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 
   29 Known 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 
   43 Required 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 
   78 Possible 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 
  111 Evaluation 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 
  131 Definitely Not-till-after-1.0 thinkings:
  132 
  133 The current "file list" is bad. It is pseudo-sorted by depth (probably).
  134 The GNOME fe wants a proper directory tree representation.
  135 
  136 To allow the possibility of doing the "spot moved directories" test,
  137 we might want a proper dirtree; but, this is a complex task, and might
  138 be achieved in another way.
  139 
  140 To get decent "checkmoved" operation, need better than O(n) lookup.
  141 O(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 
  153 Things 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 
  161 XSitecopy 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 
  170 Future 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 
  177 Longer 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.