-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Siddhant Goel wrote: > Hi. > I guess my concepts were twisted. I have made a new proposal, > incorporating what all you have suggested me, and what all I have been > able to grasp. > I have proposed my solution here - > http://siddhantgoel.googlepages.com/gsoc_gnu.pdf . > Please tell me if this one is fine, or if something needs to be > added/removed/edited.
Thanks, Siddhant; I think this version is much improved over the previous attempt. 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). 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. The "local_filename" and "localpath" entries seem redundant to me. And "chain_of_redirects" doesn't map very well to the expectation that Wget write available information as soon as it can, so that as much information is available as possible when it is read back, even if Wget was interrupted. The chain of redirects will probably be better implemented as separate entries for each redirect. 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. 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. 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?). 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. 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. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Xz+7M8hyUobTrERArehAKCKXYkP39rreVaAFnErbs0Bq6+DJACeP5aG zQkWsvyse8hkooZQ4tbYt10= =W72v -----END PGP SIGNATURE-----
