-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hrvoje Niksic wrote: > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > >>> I vote we stick with C. Java is slower and more prone to environmental >>> problems. >> not really. because of its JIT compiler, Java is often as fast as >> C/C++, and sometimes even significantly faster. > > Not if you count startup time, which is crucial for a program like > Wget. Memory use is also incomparable.
Yes, and you're right that this is crucial for Wget. However, I do not believe that it is as crucial for "Wget 2". Wget is heavily used for single-file fetches; I do not anticipate that to be the primary use for "Wget 2". They will have different application domains, and different target "markets" (see the "Thoughts on Wget 2.0" thread). This is a major reason why I advocate the name change, as I don't think the new beast can appropriately be called by the same name as what people are now accustomed to. The New Wget will almost certainly be bulkier, more expensive to build and run, and depend on a variety of other libraries and tools. It will also be more powerful and flexible, hopefully justifying these costs. But Wget's current domain will always find great use in a sleek and still-very-powerful web fetching tool with a smaller footprint and dependencies set. In essence, this drive for a "New Wget" is my way of saying, all these fancy features like multiple connections, abstracted interfaces with the filesystem, etc, support for MetaFile and JavaScript, etc, etc, are _not_appropriate_for_Wget_; while still allowing these ideas to continue (in another form). :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUFMu7M8hyUobTrERAmsrAJ9hpPCUI8IE1pKLmthCkU7MQIb9oACeIFIP TxzIeIJnDWRKUBpxdIfQzrQ= =RJwS -----END PGP SIGNATURE-----
