						-*- text -*-
Bugs and feature requests which have been reviewed are tracked in the
issue tracker at https://github.com/notroj/sitecopy/issues; what
follows is the remainder of the historical list.

Bugs:

- "sitecopy foo bar" always process foo and bar in the order they
  are specified in the rcfile

- review w.r.t djb's FTP interop notes, http://cr.yp.to/ftp.html

- Synch mode won't maintain symlinks.
- "sitecopy --rcfile=/" should say the right thing

Known Standards Compliance Problems:

- RFC959: handle telnet control characters?
- RFC2518: accept collection URI's in DAV:href without trailing slash
- RFC2617: support 'domain'

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

- Move use_this out of struct site, use proper data structures in console
  frontend to represent sites passed on cmd line.
- Anything in the below list.
- Do the hash table thang.

Required Features for one-point-oh:

- A --force-overwrite to force updates... maybe --prompt-overwrite too.
- Filename conflict resolution for update mode, as per bug... or at LEAST,
  conflict detection: can be done in file_set, not too hard probably.
- Read HTTP proxy from HTTP_PROXY/http_proxy environment variable.
- Document files list order dependancies.
- Do default ports, netrc lookups for the proxy too
- Get warning (i.e. non-fatal) messages to the user.
- Check remote directory exists on initial connection in FTP (chdir/ls)
- Because it's The Right Thing, add hash table indexing of files list.
  Hash using DJBs *33 hash algorithm. Open hash so we don't have
  worry about filling the table up. Size the hash table in the range
  100kB-200kB to not give too much run-time bloat, but not to fill up
  with reasonable-sized sites too quickly. Maybe do a user survey to determine
  optimum hash-table size.
- "include" option to mirror "exclude".

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

- Console: don't read local site state in --fetch mode.
- Support FTP proxying (how?): there are several different ways this is done...
- Support for Content-MD5 header and allow server-side MD5'ing, rather
  than having to download, checksum and discard. (remote-checksum)
- Symlink 'maintain' mode for FTP: can you create symlinks over FTP???
- Write complete documentation using GNU texinfo or DocBook, for a 
  printed manual and info pages.

Possible features, which need more consideration:

- 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).
- 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'

Evaluation of sitecopy alternatives: weex

- weex beats sitecopy 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 correct 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...

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) 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.
