-*- text -*-
Bugs:

- 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. Another nice one is:
	mv foo tmp
	mv bar foo
	mv tmp bar
  Which, in renames mode, will be correctly discovered, but when we
  do an --update... bang.
- "sitecopy --rcfile=/" should say the right thing
- If a directory is excluded, then after doing a --fetch, the files
  *within* the directory won't get matched by the excluded pattern
  necessarily, (think 'exclude CVS'), so they aren't excluded.
- The man page does not make clear what "exclude" excludes *from*.
  The point that exclude will translate into deleting existing files
  from the remote site is important and confusing.

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

Slated for 0.11 release:

- Move use_this out of struct site, use proper data structures in console
  frontend to represent sites passed on cmd line.
? Have pdriver fetch_list handler call file_set_* directly?
- Anything in the below list.
- Do the hash table thang.

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... 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
- 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)
- In davdriver.c:dir_remove, check whether the collection is empty before
  deleting it.
- 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:

- "sftp" support; FTP-over-SSL
- 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:

- When there is an error, the output can be like:

Deleting foo: failed:
423 Locked

  which unnecessarily uses two lines. Choices:

1) Forget about it. No big deal.
2) Detect line-lengths (have the code in linelen.c)
   and only separate the errors out if they are going to wrap. Might
   be impossible because of i18n stuff.
3) Don't separate the lines ever.

- Nicer progress bars. cadaver has the fe_t_p implementation, but it will
  mean two-line output per file, which is a shame.
- 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'

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...
- Big problem is that FTP fetch mode is crap.

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.

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.