
** Definitely Required Features **

- Places where a request is made before an UI feedback is given after
  running a command: do_copymove
- Copy/move over existing file gives 412 failed. PROPFIND the destination
  and prompt/fail (option!).
- restart downloads/uploads if they time out: use byte ranges? 
- If PUT in 'edit' sequence fails, offer to save locally (idea from Lee M)
- redirectref: What command to use? 'ln' == HARD links == DAV BIND !=
  DAV refres. 'alias' might be good, since it is like Apache's Alias
  directive, and is equivalent. Or 'mkref', like the old spec had MKREF.
- 'rget' and 'rput' to do recursive get/put: mkcol/mkdir where necessary
- configurable sort order of 'ls' response
- the need for some kind of resource state caching is increasing: 
  remote glob expansion needs it. we need to know whether ANY resources
  we act on are collections to do locking properly, so locking needs it too.
  we really want to do this is a little hash table, indexed by URI, which
  is only used for one command execution cycle:
   parse -> expand globs -> add trailing slashes -> execute
  We are very chatty over the wire at the moment.
- readline filename completion for remote filenames - filename complete
  local or remote depending on scope.
- Test progress bar over slow links.
    - Show activity with a spinning bar |/-\
    - Bytes done / todo as human-readable strings: 15k/200k
    - Maybe a speed too, but these are often misleading/badly calculated
    - Danger of information overload.

  Download  [===============>            ] 88% (15K/2Mb) at 2.5Kb/s /

  Display this only if isatty(stdout).
- Some better handling of mv/cp over same resource: 'mv foo foo' could
  give better error.
- ls is inflexible, should take multi-args, maybe not default to 'ls -l'
  style... allow different properties to be displayed.
  would be ultra-swish: dav> dcls
  Type  Resource name    Dublin Core Title
  Res   rfc2518.txt      HTTP Extensions for Distributed Authoring -- WEBDAV
  Res   rfc2616.txt      Hypertext Transfer Protocol -- HTTP/1.1
  Completely configurable fields/widths/orders would be nice.
- properties: display all... display from namespace 
  (draft-stracke-webdav-propfind-space)... display Dublin Core...
  set specific. Lots of scope.
- verbosity level for connection status messages
- man page
- PROPFIND issues, try http://sandbox.xerox.com:8080/joe.orton/

** Longer-term Required Features **

- DASL searching, redirect references, ordered colls, binding... 
  some server support for the last three would be nice first ;)
  We have better XML response support now, so these shouldn't be quite
  such a beach to implement.

** Code Issues **

- may have to consider some "proper" URI handling, i.e., using a URI
  ADT... this is bothersome, since thus far, we have managed to cope
  with just using strings (i.e. the absPath segment), which makes for
  a nice simple, efficient, easy-to-use API.
- http_init sucks. the OPTIONS step should never have been there.
- the glob in glibc-2.1.3 won't be broken, so we can use that instead
  of our included one, need an autoconf test for it. But it probably
  won't have the interrupt_state interface, so maybe we should just
  stick with rolling our own.
- do something about the bool/curses clash.
- should probably get rid of the global state in cadaver.c/commands.c etc
- Better mapping between aliases and commands: ideally, the aliases would
  be declared statically in the command structure, but I can't see any
  way to do this in C. It would be nice to be able to do command->aliases
  mapping easily, too.
- Bring the sitecopy UTF-8 fix across into hip_xml.

** WebDAV issues **

- Ignore unknown XML elements in more places.
- See also sitecopy TODO
- There are caveats about proxies in places.

** WebDAV Locking Issues **

- 'capable' command, or something, for capability discovery.
  this could be not specific to locking, doing OPTIONS too?
- have lockowner as option
- bad interop against mod_dav with collection locking.
- need to interop test against Xythos, IIS, PyDAV
- shared locks
- plug the leaks.
- put full URI in lock->uri
- have locks follow MOVE's?
- make sure DELETE removes lock internally

** Possible features **

- Run a command from the command line, e.g.
       cadaver --command="get asda.txt" http://www.wherever.com/some/where/
- at the mo, 'cd' does a PROPFIND/depth0... could (optionally?) do a
  PROPFIND/depth1 instead to save a round-trip, and cache the results.
  ditto for globbing.
- Generic mechanism for running commands locally (optionally, passing
  a downloaded remote file?)... abstract out "edit" functionality, which
  has two parts:
     1) the LOCK -> (do stuff) -> UNLOCK  sequence
     2) Download resource to temp file, execute command, passing temp file
- could also interpret known status-codes with more friendly responses.
  e.g. 423... 401... 404... maybe some extra explanation for 5xx responses,
  since they tend to be "something is broken" type errors.
- command options
- color 'ls'
- read sitecopyrc file for host/username/password+proxy
- netrc files are a bit outdated... maybe extend the syntax
  somewhat? Better, invent "~/.inetrc"? index by URL:
   location http://www.wherever.com/mysite/
     username joe
     password secret
   location ftp://ftp.server.com etc etc.
  would be nice, can store different username/passwords for
  different services then... imap:// too etc.

** Misfeatures (a.k.a. known bugs) **

- See INTEROP for known interoperability problems
- cadaver really sucks in the "reinvent all the user-space tools inside
  a single program" kind of way, do DAV at the filesystem layer instead.
- rm * is a bit dangerous... 'interactive' option makes like -i option
  to shell tools.
- We have a problem with 'delete'.

   DELETE in WebDAV is equivalent to "rm -rf" in Unix -> i.e, by default,
   it is the most dangerous form of delete.
   
   1) We could make 'delete' only work on non-coll resources:
   BAD: Then we need a different command which works on colls.. 'rmcoll'

   2) We could leave 'delete' as it is, and prompt if used on colls.
   QUITE BAD: prompts suck.

   3) We could leave 'delete' alone.
   VERY BAD: rm in Unix is not as dangerous as rm in cadaver, users 
   DO NOT EXPECT 'cadaver rm == Unix rm -r'.


