minor
 - if user tries to add a directory, give an error
 - make sure initial addition information handled correctly
   eg what if initial addition and both files exist?
 - don't let user exit while sync occurring
 - if initial db open fails, report error and let user choose
   to truncate file (?)
 - use error functions for gnome-app.
 - be smarter about handling serious errors.  an "OK" dialog is
   a bad solution -- what can the user really do?

baseline
 X use berkeley db to store info
   database maps local file name to remote file name and checksum
   (stored as two adjacent strings in one buffer)
 - use mc-vfs to allow all kinds of synchronization
 X application has two modes:
   1. edit sync list
   2. actually synchronize
   can share parts of gui.  need two different desktop entries though
 X drag-n-drop file names
 X all work is done in background, keeping ui responsive
 X allow concurrent transfers of multiple files
 - show progress of each transfer, along with overall progress
 X put errors into a list that shows local/remote, file name, and
   error message.  let user do different things: retry, remove from
   database, etc.
 X have "resync" button that will retry everything again; this clears
   error/info windows and restarts.  will cancel fetches in progress
 - options to make backups of various kinds
   (follow emacs)

 X if just_sync, then should exit(0) if no errors found
   otherwise pop up window per usual; error window must have way to
   get back to main window (or just have one window?)
 - copy to temp file and then rename when successful
   (won't work well with vfs if we are naive...)
 - allow direct editing in clist window.  At least via dnd.

options
 X maximum cache size (or max file size?) to keep in memory
 X maximum number of concurrent local transfers
 - ways to control progress display
 - name of floppy device (or directory?)
 - colors?  (of normal fg, error fg)

optimizations
 X mmap local files
 - try to use stat to precompute buffer size (works with some fs, not others)
    [ right now we use fstat, but stat might be better with VFS ]

future
 - allow entire directories to be sync'd
   this is more complex.  for instance, must handle cases where file
   is added or removed remotely or locally
 - allow user to specify a diff/merge program to see what has changed
 - have mode where no changes are done automatically, but all are flagged
   for preapproval
 - let user keep multiple sync databases
 - ignore special files
 - save state of merge window in session

 - figure out a way to allow easy synchronization via a floppy
   put stuff into a tar file?  One idea would be to have a new kind of
   file (".sync") which would be a database file.  A floppy would
   have a .sync file and a tar file; the references in the .sync file
   would point into the tar file.  The user could just double-click
   on the .sync file to synchronize the floppy with the local machine.
   Maybe having a .sync file be a tar file with a special entry would
   be better?  First think about the most natural way for sync-via-floppy
   to work for the user...

 - version control

unimportant ideas
 - programs to allow read/write of databases from shell
   (or a parser for rdist-like files?)
     [ probably this isn't important -- people who understand rdist
       or rsync will use them instead ]
 - sync program must have non-X mode so it can be used like rdist
     [ likewise, not very important ]

configure

vfs
 - write rcp/scp vfs back end
   use rcp with a named pipe for copying
   use rsh+ls to look at directories
   3 types: rcp, scp, and `rcp -x'.

rewrite
 - rewrite to have generic file read/write code, with callbacks
   for when buffer read or written
