The interesting part of moving these downloads to a background child process is that we have already started the curl download, and somehow we have to stop it in the parent and keep it going in the child, all from a callback function. In the parent, after the fork, I could setjmp back up the stack, I know how to do it, but as ANA said in A Taste of Armageddon, "It would frighten any sane man." Who knows what sort of curl states would be left about. So I return -1 from the callback function, and hope curl unwinds the stack properly, *without* aborting the transfer on the server side. So far, for ftp and http, it does. Have not tested ftps, sftp, or tftp. The secure ones might be an issue, and similarly for https, also untested. A future version of curl *might* act differently, and tell the server to hang up, and then this design won't work. for now, ftp and http work. I may have to manufacture tests for ftps and https, unless someone knows of some handy secure download sites on the net.
Another suboptimal consequence, that we can't do anything about, is that you can't dawdle when asked for a file name. The curl download is already in progress, and the server side could well time out if it takes you two minutes to decide where to put the file. Fortunately, most people will take the default file name provided by the server, or type in a quick temp file name to go to the download directory and then move it later. That's fine. I suppose I could test the limits, how long can I delay, at least here with my local servers apache and vsftpd. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
