
Bugs:

- So far unreproducable synch mode bugs reported by David Massart
- Possible that the WebDAV 422 seen against Cyberteams is a sitecopy
  bug.
- Fetch mode for FTP rarely works
- Synch mode won't transfer in ASCII mode, nor maintain symlinks, nor
  correctly order file deletions.
- Filename conflicts are not handled by update or synch mode: case:
  Directory exists remote called "foo". Delete locally, replace with 
  file called "foo". Try an update. Bang.

Known Standards Compliance Problems:

- RFC959: handle telnet control characters?
- RFC2518: accept collection URI's in DAV:href without trailing slash,
           parse DAV:status
- RFC2617: possibly realm, domain issues. auth-int untested.

* anything with (FEAPI) after requires frontend API change, not including
  simple config options additions

Slated for 0.10:

- Use libneon for better 207 errors
- Get WebDAV authentication errors to return SITE_AUTH from site_* 
  functions.

WebDAV:

- Integrate 'libdav' code from cadaver.
  ignore 4xx resources, do something meaningful with 3xx-type resources:
  fetch DAV:reftarget property and read symlink target. Report 5xx as error?  
- WebDAV: do compressed transfer-encodings (use zlib?).
  Better error messages. Pipelining would be nice, but hard (FEAPI).
  PROPFIND: Okay to use encoding= etc? (not atm, it breaks IIS5-beta) 
- There are quite a few issues which need resolving before CGI files can
  be properly maintained via WebDAV:
   - the difference bewteen the "source" (static) resource, and the
     "output" (dynamic) entity... i.e. GET on a script is output, not source.
     This can be resolved at server configuration.
   - mod_dav is set to support an "isexecutable" live property some day,
     support this by doing a PROPPATCH
   - Access permissions could come in the form of the ACL extensions
     (draft-ietf-webdav-acl-??.txt), or it could be done using some custom
     live properties.

Required Features for one-point-oh:

- Verify mode, also a --force-overwrite to force updates... maybe 
  --prompt-overwrite too.
- Filename conflict resolution for update mode, as per bug.
- Read HTTP proxy from HTTP_PROXY/http_proxy environment variable.
- Support FTP proxying (how?)
- Document files list order dependancies.
- Do default ports, netrc lookups for the proxy too
- Report corrupt info files back to the user (FEAPI)
- Check write return codes in site_writefiles, signal the error if
  the info file doesn't get written properly.
- Get warning (i.e. non-fatal) messages to the user.
- Check remote directory exists on initial connection in FTP (chdir/ls)
- Better FTP fetch mode... maybe integrate the ls parser from mc.

"Would be Nice to Have But We Can Live Without" features:

- Symlink 'maintain' mode for FTP: can you create symlinks over FTP???
- Support the proprietary Microsoft Frontpage HTTP POST-based protocol.
- Frontends using other GUI toolkits, e.g. Qt, fltk, wx-Windows, Windows 
  native, (n)curses.
- IPv6 support.
- "Check server" function, --check-server, probes for 100-expect capability,
  gives Server: line, authentication level etc. Could go further and
  include a complete method test suite... compile-time option, maybe. (FEAPI)
- Env. var CONF_PREFIX which is used to choose rcfile+storepath like:
    $HOME + $CONF_PREFIX + sitecopyrc
- Nicer rcfile format - lex'n'yacc?
- Write complete documentation using GNU texinfo or DocBook, for a 
  printed manual and info pages.

Possible features, which need more consideration:

- Per-site lockfiles (FEAPI)
- Shortcircuit parm in file_set_* used for the FIRST site state read on a 
  site, to make the file search always fail - guarantee to be true, since if we
  read local state before stored state, there is no stored state in the
  list when we read the local state.
- Console: Some kind of 'first-time-use' option, `sitecopy --first-time'
  runs a wizard a la the GNOME fe's one.
- Support for other better/faster checksumming algorithms: is SHA1
  better/faster? (GPL implementation in GnuPG)
- Backup info file on write_stored... optionally? Only implement in frontend?
  GNU-style $VERSION_CONTROL support?
- Have 'preconnect' and 'postconnect' options which run user-specified
  programs before and after an update, synch etc.
- Some kind of user-feedback for slow startup in checksumming mode.
  takes approx 1 sec to MD5 a 10mb file on a K5 166 -> okay for average-sized
  sites. (FEAPI)
- Abstract protocol drivers into a mc VFS-like 'open', 'read' etc.
  Abstract sites code so that "local" and "remote" can be handled by any 
  of {file, http, ftp}. Then, update + synch could possibly merge, since
  an synch is an update with the remote and local sides switched (kindof).
- Allow file->file sites (screem wants this)... as above, or simply by
  implementing another protocol driver.
- consequently, read ls-laR.txt files and be more like 'mirror'
- Add quota management, specify a per-site quota and only do update
  if the result means the site will stay under quota.
  -> problem: a directory uses up k's, but how many?
- Abstract protocol drivers into a mc VFS-like 'open', 'read' etc.
  Abstract sites code so that "local" and "remote" can be handled by any 
  of {file, http, ftp}. Allows file->file sites, which screem wants.
- Read ls-laR.txt files and be more like 'mirror'
- Have a list of files which are downloaded on every --update; e.g.
  log files, web counter files, guestbooks, etc etc.

Evaluation of sitecopy alternatives: weex

- weex beats us hands-down in new user ease-of-use: you just run it.
  With sitecopy you have to do --fetch or --catchup first. This situation
  is slightly improved in 0.9, where on the first 'sitecopy newsite' 
  invocation, you get told what to do next.
- sitecopy could improve by doing:
  an interactive 'on first run for site', like the GNOME fe site
  creation wizard. This could create the .sitecopy directory with the
  correct permissions (but I am a bit dubious about this).
- Another alternative is the --first-time option. This could do:
   mkdir .sitecopy with perms
   create .sitecopyrc with correct perms
   ? enter a complete site definition, and run --init, or --fetch, 
   or catchup, as appropriate.
  This could either be run automagically if no .sitecopyrc file is
  found (don't let trigger by --rcfile= option), or, better, by a message
  telling you to run --first-time.
  --new-user might be better...
- Big problem is that FTP fetch mode is crap.

Console frontend specific features:

- console: Allow user to update just a single file? --only=...?

Definitely Not-till-after-1.0 thinkings:

The current "file list" is bad. It is pseudo-sorted by depth (probably).
The GNOME fe wants a proper directory tree representation.

To allow the possibility of doing the "spot moved directories" test,
we might want a proper dirtree; but, this is a complex task, and might
be achieved in another way.

To get decent "checkmoved" operation, need better than O(n^2) lookup.
O(1)-ish could be achieved using a a hash table.

- Find operation on the files list is O(n), making state reads O(n^2).
  Hashing would be nice -> can use the MD5 csum.

- Intelligent file movement detector, to spot whole moved directories:
  Possibly implement by checksumming relative filenames for EACH 
  directory (fairly nasty overhead); so each directory has a 
  children_checksum field. Need a clever checksumming algo; MD5 would
  require identical ordering, which would be a heavy constraint.
- Make the protocol drivers and sites code thread-safe.

Things You Might Like to Do On A Rainy Day:

- Investigate any extra handling needed for servers which have case
  insensitive filenames
- Native Windows port (e.g. reimplement socket.c using the Winsock API)
- Convince the maintainer that it's more productive to spend time 
  implementing features than carefully crafting a mile-long TODO list.

XSitecopy TODO
--------------

- Tooltip(s) for the site widgets; specifically safe mode.
- Integrating resynch into the app.
- View files using gnome mime types.
- Transition from time-size to checksum.
* Prefs

Future releases:

- Bring back optional 'slim' mode which will take up less desktop real estate.
- Popup menus for the site/file tree.
- Single file updates.
- Update all.

Longer term things:

- Panel applet for easily updating sites in a couple of clicks.  
- Html based reports - integration into FE apps, and possible auto uploading
  to the remote site. (useful as a "recent changes" page)
* Please send any suggestions you may have as to the format/design/type of
  reports that you might find useful.
