1 2** Bugs ** 3 4- mput will try to upload directories 5 6** Requested Features ** 7 8From Jules <jules@jules.com>: 9> Now the request: I use gvim -f as my editor and it would be great if 10> there was an option for Cadaver to upload the file on each :w (or a 11> switch in my ~/.cadaverrc). That way I wouldn't have to save and quit 12> gvim each time I wanted the file to go back on the server. 13 14** Definitely Required Features ** 15 16- Abort download/uploads? 17- Places where a server request is made before an UI feedback is given after 18 running a command: do_copymove 19- Copy/move over existing file gives 412 failed. PROPFIND the destination 20 and prompt/fail (option!). 21- restart downloads/uploads if they time out: use byte ranges? 22- If PUT in 'edit' sequence fails, offer to save locally (idea from Lee M) 23- redirectref: What command to use? 'ln' == HARD links == DAV BIND != 24 DAV refres. 'alias' might be good, since it is like Apache's Alias 25 directive, and is equivalent. Or 'mkref', like the old spec had MKREF. 26- 'rget' and 'rput' to do recursive get/put: mkcol/mkdir where necessary 27 ...use infinite-depth PROPFIND? 28- configurable sort order of 'ls' response 29- the need for some kind of resource state caching is increasing: 30 remote glob expansion needs it. we need to know whether ANY resources 31 we act on are collections to do locking properly, so locking needs it too. 32 we really want to do this is a little hash table, indexed by URI, which 33 is only used for one command execution cycle: 34 parse -> expand globs -> add trailing slashes -> execute 35 We are very chatty over the wire at the moment. 36 One way of implementing this would be on TOP of neon (i.e., cache the 37 decoded RESULTS of the PROPFIND). Another way to do this would be 38 INSIDE of neon: cache (like a normal Web browser caches stuff) the 39 PROPFIND response entity-body and supply that on demand. But the RFCs 40 say no-go to caching PROPFINDs, so probably not an option. 41- Test progress bar over slow links. 42 - Show activity with a spinning bar |/-\ 43 - Bytes done / todo as human-readable strings: 15k/200k 44 - Maybe a speed too, but these are often misleading/badly calculated 45 - Danger of information overload. 46 47 Download [===============> ] 88% (15K/2Mb) at 2.5Kb/s / 48 49- Some better handling of mv/cp over same resource: 'mv foo foo' could 50 give better error. 51- ls is inflexible, should take multi-args, maybe not default to 'ls -l' 52 style... allow different properties to be displayed. 53 would be ultra-swish: dav> dcls 54 Type Name Title 55 Res rfc2518.txt HTTP Extensions for Distributed Authoring -- WEBDAV 56 Res rfc2616.txt Hypertext Transfer Protocol -- HTTP/1.1 57 Completely configurable fields/widths/orders would be nice. 58 It would be rather groovy to have a DAV-enabled Dublin-Core indexed RFC archive. 59- properties: display all... display from namespace 60 (draft-stracke-webdav-propfind-space)... display Dublin Core... 61 set specific. Lots of scope. 62- verbosity level for connection status messages 63- man page 64- PROPFIND issues, try http://sandbox.xerox.com:8080/joe.orton/ 65 66** Longer-term Required Features ** 67 68- DASL searching, redirect references, ordered colls, binding... 69 some server support for the last three would be nice first ;) 70 We have better XML response support now, so these shouldn't be quite 71 such a beach to implement. 72 73** Code Issues ** 74 75- Maybe put a union in struct command to get better typesafeness... 76 the Apache 2 config uses some GCC trickery to help. 77- set_path/is_collection is screwy. 78- may have to consider some "proper" URI handling, i.e., using a URI 79 ADT... this is bothersome, since thus far, we have managed to cope 80 with just using strings (i.e. the absPath segment), which makes for 81 a nice simple, efficient, easy-to-use API. 82- should probably get rid of the global state in cadaver.c/commands.c etc 83- Better mapping between aliases and commands: ideally, the aliases would 84 be declared statically in the command structure, but I can't see any 85 way to do this in C. It would be nice to be able to do command->aliases 86 mapping easily, too. 87 88** WebDAV issues ** 89 90** WebDAV Locking Issues ** 91 92- 'capable' command, or something, for capability discovery. 93 this could be not specific to locking, doing OPTIONS too? 94- shared locks 95- put full URI in lock->uri 96- have locks follow MOVE's? 97 98** Possible features ** 99 100- Have edit poll for changes, and PUT on modification? 101- Run a command from the command line, e.g. 102 cadaver --command="get asda.txt" http://www.wherever.com/some/where/ 103- at the mo, 'cd' does a PROPFIND/depth0... could (optionally?) do a 104 PROPFIND/depth1 instead to save a round-trip, and cache the results. 105 ditto for globbing. 106- Generic mechanism for running commands locally (optionally, passing 107 a downloaded remote file?)... abstract out "edit" functionality, which 108 has two parts: 109 1) the LOCK -> (do stuff) -> UNLOCK sequence 110 2) Download resource to temp file, execute command, passing temp file 111- could also interpret known status-codes with more friendly responses. 112 e.g. 423... 401... 404... maybe some extra explanation for 5xx responses, 113 since they tend to be "something is broken" type errors. 114- command options 115- color 'ls' 116- read sitecopyrc file for host/username/password+proxy 117- netrc files are a bit outdated... maybe extend the syntax 118 somewhat? Better, invent "~/.inetrc"? index by URL: 119 location http://www.wherever.com/mysite/ 120 username joe 121 password secret 122 location ftp://ftp.server.com etc etc. 123 would be nice, can store different username/passwords for 124 different services then... imap:// too etc. 125 126** Misfeatures (a.k.a. known bugs) ** 127 128- See INTEROP for known interoperability problems 129- rm * is a bit dangerous... 'interactive' option makes like -i option 130 to shell tools. 131