Hi, I've had a lot of work through examination period but now I'm back and
I'm ready to work only on libcurl.

First of all I'd like to ask you if there is a big problem with source
size (binary size/number of source lines) or code complexity. I know, that
it is possible improve library without recoursive and "ftp://site/*/*/*.c"
idea, but it could be much more useable for app programmer.. I really hope
the concept is not so much difficult to understand by next libcurl
developers and this little complexity could good balance with useability
of this enhancement.

Next I really considering to parse LIST response. Even if we discard the
recoursive idea (but I'd like rather do this), we have to let the app
programmer know the matched filename is directory -- to allow him to
create new curl handle and start with wildcard downloading in subdirectory.

And the multiple-calling curl_easy_perform idea -- it could be a little
inconsistent behavior from libcurl and I think it is not really necessary.

Here is the easy-to-use wildcard callback prototype.

/**
  * function is called by libcurl before the downloading started
  * - user can set/change/keep the FILE * pointer
  * - user can discard downloading -> return FALSE value.
  * - libcurl have to reinitializate progressbar before calling
  * this callback
  * - filetype is enum dir/file to allow user easy to create
  * directories if it is important for him
  */
int wildcard_callback(char *matchedstring, FILE *f,
  int filetype)
{
   // keep "f" or close it and open new .. by default keep on "f == stdout"
   return 0; // discard downloading this file .. or
   return 1;
}

Question is where to close "FILE *f" when it is changing. The last
download pointer will stay unclosed if we close it in callback. But the
callback can be e.g. called once again after all matched files are
downloaded (with matchedstring==NULL) to let the app programmer know that
everything is done and allow him close the last filename. Callback could
be called with matchedstring==NULL when no match occurred too.

The example neglects statistics about how many files is in directory, how
many is matched and which of them is downloading now -- which is
theoretically not important because each matched file can have
significantly different size.

And I have forgotten to idea about deepness of recoursive match, I think
it is easy to implement in libcurl too. The CURLOPT_RECOURSIVE could be
integer - and "0" does mean no recoursive match (default), "-1" unlimited
and positive values could set concrete deepness ..

I need to know your opinions before I start working on it. My target is to
find most useable solution which is still acceptable. And yes, I know it
will cost lot of work but it is not a problem for me.

Thanks, Pavel
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-01-27