-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles wrote: > On Mon, Mar 17, 2008 at 1:52 PM, Micah Cowan <[EMAIL PROTECTED]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> The Wgiki now holds quite a few ideas regarding the proposed session >> database: >> >> http://wget.addictivecode.org/FeatureSpecifications/MetaDataBase >> >> Please check it out, offer suggestions, make improvements, etc. This is >> one of the features that went on the Google SoC ideas list. > > I'd like to suggest that, maybe
Wow, that was fast. > - The session database can be used to save a list of links to be > downloaded, like the other graphical download manager have. Or even a > scheduled download. > > The scenario would be something like > > wget --add-link http://something > wget --add-link http://anotherthing > wget --add-link http://something --schedule 23.30 > wget <- read from the database of unprocessed downloads and download them > # while the wget is still running > # add another link > wget --add-link http://more-link-added I don't really see that as Wget's domain; this same sort of thing is achievable with something like: echo http://something >> links echo http://anotherthing >> links echo wget http://something | at 23:30 wget -i links Adding links/changing config on-the-fly in Wget is an interesting feature, but isn't really related to the meta-database. > - Also how about the performance of the database? I do not think that > a human readable format will give a good performance. No, it won't be, and neither will it need to be. The files, even for large fetches, will almost certainly be quite small (relative to typical RDBMS application space), and will easily be parsed and the appropriate internal data structures set up in well under a second for most cases. However, I think you missed the mention that a binary-format alternative could be provided (with Wget using timestamping to judge whether it's out-of-date). The databases will be quite small, compared to typical > Creating a > binary version with index is like reinventing the wheel IMO where > embedded database like SQLite, or Berkeley DB would provide out of the > box. Instead, why not use an embedded database for storage and add a > utility to read/process/update the database. An embedded database is overkill, and I'd rather not introduce such dependencies (and such huge dependencies!) where I can help it. However, I did have in mind that one or more utilities would be added at some point to deal with the database in various ways. > Using something like a popular embedded database will also give easier > interoperability of the data IMO. I can create a code in some > interpreted language to read the database in much shorter time if the > data is saved in an SQLite database instead of a text file with format > specification (would have to create the parser first) or a proprietary > binary format. And I can use good old Unix text-processing utilities in an even shorter time than that, I imagine. No, I have no interest in using even Berkeley DB for this sort of thing. Unix derives quite a bit of its power and flexibility from its tendency to keep many things in human-readable/editable file formats. I also would not be interested in using XML as the basis for this file format; I don't see that it would bring much advantage, and its much less human-editor-friendly. > OK, that's some suggestions I have. Thanks for your time :D And yours. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3ini7M8hyUobTrERAkRvAJ4ia9v2ixCTHRRKZXFiiKSo/ilpiQCcCy61 jurwhVUKGAuHumFExeHP6wY= =t5jC -----END PGP SIGNATURE-----
