The more important detail is that the code should be written in a clear and concise way with enough comments so that it becomes easy enough to read.
Of course, it is commonplace.
Possibly, but with recursion you also get more features. Perhaps an app wants different patterns in different subdirs?
CONCEPT IDEA: Yes, but in this case app programmer can use simpler "version" of enhancement - without recoursive version.
Perhaps the app wants to limit the depth of the tree traversal?
CONCEPT IDEA: Limit depth is the smallest problem, i propose implement it as new CURLOPT.
Perhaps the app wants to exclude a specific single dir from the traversal?
CONCEPT IDEA: Excluding a specfic dir is possible by the callback. I'm not sure if I mentioned it but it could be one parameter of the callback which tels: "it is directory".
If we can't offer these features, we may end up in a situation where all apps that want recursion STILL implements it themselves simply because our way is not flexible enough and then we have an implementation that adds complexity for no additional benefit.
CONCEPT IDEA: Yes, I agree and because of that I'd like to offer simple effective wildcard version + recoursive option + depth option. User can choose the best way for him.
I also miss total number of files and total size of all files (which you mentioned further down in your mail but I didn't understand if you have decided not to include them or not).
There is a little problem in recoursive version. If we not reject the recoursive idea, checking the total number of files and their size could be inefficient and not appropriate to the information value. The true is that it is not impossible but would it be necessary?
What is 'matchedstring' ? Is that the directory entry name?
:-) I meant parameter "matchedstring" like filename which corresponds to the pattern. For this filename is callback called by libcurl.
I also like a differe error code usage. Just using TRUE/FALSE tends to end up a mistake. Use 1 and 0 instead explictly, and everything else is reserved for future use. That allows for a future libcurl to introduce new return codes without breaking old apps.
Thank you for notification, it is better. Now I wonder there could be a special return codes for directories, symlinks etc. in future.
The wildcard callback is called before each transfer so it would basically say "here comes a new file". That means the previous file ended and it would have to be closed, or similar. A bit awkward I'd say (especially for the last downloaded file). Possibly we should consider one callback before and one after each file.
Or as Kamil Dudka says in parallel response, we can call the function before the transfer starts and second time as soon as the transfer finished. It could be easier way to use. Note 1 - "CONCEPT IDEA" does mean that I'd like to do this like this, but I'm not sure I can do it completely on time (because of bachelor thesis time limit) .. Priority is implement the most simple way ftp://example.tld/*.txt Note 2 - ftp://example.com/dir1/* does mean (in my recoursive idea) all files in /dir1 + all subdirs (as deep as is set). And if there is on server ftp://example.com/dir1/ and ftp://example.com/dir2/ .. and user sets URL ftp://example.com/*/* with recourse, it will download all files and subdirectories from dir /dir1 and /dir2. First wildcard matches ONLY directories. Note 3 - user everytime can use ftp://example.com/*.txt ignoring recoursive enhancement and ignoring the "directory call". New possible prototype of callback: callback(char *filename, void *ptr, (enum)type_of_call) where type_of_call could be DIRECTORY/START_TRANSFER/STOP_TRANSFER/errors. When is function called with DIRECTORY flag, user can skip (if recoursive is ON) downloading the directory he wants not to download and if recoursive is OFF, it is not necessary to call the callback by libcurl at all. I propose parameter "filename" is absolute path to file. I think it could be the right time to start working on the code. Pavel ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
