> > > Thanks, Siddhant; I think this version is much improved over the > previous attempt. >
Thank *you*! I have revised it again and its waiting for you! :) > I'd probably try not to get into the details of what the session db file > might look like; that's probably one of the things we'd need to define > as part of our initial discussions. I'm guessing that the list of > entries in your abstract are probably intended as only examples of the > _kind_ of data that would go in there, rather than the particulars of > how that data should look, but if I were you I'd say that explicitly. > (Also, that sort of information is probably not so appropriate in the > "Abstract", which is usually intended to be a very high-level > description of what the feature is). I have now mentioned, that the list I am providing gives a fair enough *idea* of what needs to be implemented. Also, I agree that that list should be there in the How/Deliverables section ,rather than being in the Abstract. Corrected. > To comment on some of the specific items you have in that list: I'm not > sure that "Download #" will be a useful piece of information, except > perhaps for use in identifying a resource across interleaved entries. I forgot to mention in the last proposal. I will use a download number to mainly address the issue of redirect(s). Suppose if there is a file that is being downloaded, and there happens a redirect, the current entry will be written to the file, and a new entry will start being written. The download # of this new entry will be the value of chain_of_redirects for the previous entry. > The "local_filename" and "localpath" entries seem redundant to me. Me too. I do not know what got into my head when I made such a stupid assumption. :( Corrected now. > A boolean "download_status" strikes me as not informative enough for > what we will want it for. It would be very useful to distinguish between > a download that failed due to a 404 Not Found and one that failed due to > a 403 Forbidden; as well as distinguishing between loss of connections, > failure to connect, proxy-specific failures, and name resolution failures. > For this issue, I have made two sections in an entry. A download_status value (which should be 1 if the download was successful, and 0 if it was not), and a status_reason value (which, as I see it, will contain specific codes for specific failure reasons. 1 could be for a 404, 2 could be for a 403, 3 could be for a name resolution error, and so on). > All in all, though, it's best not to focus on the details of what > entries might _look_ like, but how they will enable Wget to _use_ them. > That is, rather than saying that the session db will have "localpath" or > "chain_of_redirects" entries, it's more productive to say that Wget will > be able to be able to find the path of the locally-downloaded file > corresponding to any URI from the single URI or chain of redirected URIs > that; or that Wget will determine what files remain to be downloaded > and/or parsed to continue where a previous session left off. > This information should now be clear, as I have explicitly mentioned each and every use for each and every section in an entry, along with providing a simple procedure for a lookup at the end of the How/Deliverables section. > It'd be really nice to touch on a little bit of _how_ Wget will handle > looking up a local pathname from a chain of redirects (i.e., if you're > not going to do it by using grep for each download, how _will_ you > accomplish it?). Yes. It would surely be nice. I have added a simple procedure in the How/Deliverables section, to depict what's going on in my mind when I am thinking of a solution to this feature. > It would also be good to talk a little about compatibility issues, such > as how Wget could handle session dbs that were generated from newer > versions of Wget, that might specify information that Wget doesn't know > how to process. > I didn't quite get that. My proposal says about a slight code addition to wget in its future releases, so older versions wouldn't have a session info feature. Please correct me if I'm wrong. > Any sample code from anything you've worked on in the past, even if it's > incomplete or now embarrasses you (that's not a problem: just explain > how you would improve it) would be very helpful; something to help > determine whether you possess the appropriate skillset to handle the > task you're proposing to implement. > I had submitted a small project back in school, 3 years ago, that implemented a school management system. It was entirely written in C++, it was around 1700lines of code, and now I am not able to find it. :( :( :( I am still searching for it though; it might also be there at my school. I will update you on it as soon as I find it. Other than that, I am afraid there isn't much *code* I could present. Though if required, I can mention the exact details of what all I intend to fill into sidb.h and sidb.c files I have mentioned. Should I include that in the proposal? Or should I discuss it with you? You suggest. :) Thanks again for your time and efforts! Regards. Siddhant
