> 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
Received on 2010-01-31